1 //===-- llvm/MC/MCSchedule.h - Scheduling -----------------------*- C++ -*-===//
2 //
3 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
4 // See https://llvm.org/LICENSE.txt for license information.
5 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
6 //
7 //===----------------------------------------------------------------------===//
8 //
9 // This file defines the classes used to describe a subtarget's machine model
10 // for scheduling and other instruction cost heuristics.
11 //
12 //===----------------------------------------------------------------------===//
13 
14 #ifndef LLVM_MC_MCSCHEDULE_H
15 #define LLVM_MC_MCSCHEDULE_H
16 
17 #include "llvm/Config/llvm-config.h"
18 #include "llvm/Support/DataTypes.h"
19 #include <cassert>
20 
21 namespace llvm {
22 
23 template <typename T> class ArrayRef;
24 struct InstrItinerary;
25 class MCSubtargetInfo;
26 class MCInstrInfo;
27 class MCInst;
28 class InstrItineraryData;
29 
30 /// Define a kind of processor resource that will be modeled by the scheduler.
31 struct MCProcResourceDesc {
32   const char *Name;
33   unsigned NumUnits; // Number of resource of this kind
34   unsigned SuperIdx; // Index of the resources kind that contains this kind.
35 
36   // Number of resources that may be buffered.
37   //
38   // Buffered resources (BufferSize != 0) may be consumed at some indeterminate
39   // cycle after dispatch. This should be used for out-of-order cpus when
40   // instructions that use this resource can be buffered in a reservaton
41   // station.
42   //
43   // Unbuffered resources (BufferSize == 0) always consume their resource some
44   // fixed number of cycles after dispatch. If a resource is unbuffered, then
45   // the scheduler will avoid scheduling instructions with conflicting resources
46   // in the same cycle. This is for in-order cpus, or the in-order portion of
47   // an out-of-order cpus.
48   int BufferSize;
49 
50   // If the resource has sub-units, a pointer to the first element of an array
51   // of `NumUnits` elements containing the ProcResourceIdx of the sub units.
52   // nullptr if the resource does not have sub-units.
53   const unsigned *SubUnitsIdxBegin;
54 
55   bool operator==(const MCProcResourceDesc &Other) const {
56     return NumUnits == Other.NumUnits && SuperIdx == Other.SuperIdx
57       && BufferSize == Other.BufferSize;
58   }
59 };
60 
61 /// Identify one of the processor resource kinds consumed by a particular
62 /// scheduling class for the specified number of cycles.
63 struct MCWriteProcResEntry {
64   uint16_t ProcResourceIdx;
65   uint16_t Cycles;
66 
67   bool operator==(const MCWriteProcResEntry &Other) const {
68     return ProcResourceIdx == Other.ProcResourceIdx && Cycles == Other.Cycles;
69   }
70 };
71 
72 /// Specify the latency in cpu cycles for a particular scheduling class and def
73 /// index. -1 indicates an invalid latency. Heuristics would typically consider
74 /// an instruction with invalid latency to have infinite latency.  Also identify
75 /// the WriteResources of this def. When the operand expands to a sequence of
76 /// writes, this ID is the last write in the sequence.
77 struct MCWriteLatencyEntry {
78   int16_t Cycles;
79   uint16_t WriteResourceID;
80 
81   bool operator==(const MCWriteLatencyEntry &Other) const {
82     return Cycles == Other.Cycles && WriteResourceID == Other.WriteResourceID;
83   }
84 };
85 
86 /// Specify the number of cycles allowed after instruction issue before a
87 /// particular use operand reads its registers. This effectively reduces the
88 /// write's latency. Here we allow negative cycles for corner cases where
89 /// latency increases. This rule only applies when the entry's WriteResource
90 /// matches the write's WriteResource.
91 ///
92 /// MCReadAdvanceEntries are sorted first by operand index (UseIdx), then by
93 /// WriteResourceIdx.
94 struct MCReadAdvanceEntry {
95   unsigned UseIdx;
96   unsigned WriteResourceID;
97   int Cycles;
98 
99   bool operator==(const MCReadAdvanceEntry &Other) const {
100     return UseIdx == Other.UseIdx && WriteResourceID == Other.WriteResourceID
101       && Cycles == Other.Cycles;
102   }
103 };
104 
105 /// Summarize the scheduling resources required for an instruction of a
106 /// particular scheduling class.
107 ///
108 /// Defined as an aggregate struct for creating tables with initializer lists.
109 struct MCSchedClassDesc {
110   static const unsigned short InvalidNumMicroOps = (1U << 13) - 1;
111   static const unsigned short VariantNumMicroOps = InvalidNumMicroOps - 1;
112 
113 #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
114   const char* Name;
115 #endif
116   uint16_t NumMicroOps : 13;
117   uint16_t BeginGroup : 1;
118   uint16_t EndGroup : 1;
119   uint16_t RetireOOO : 1;
120   uint16_t WriteProcResIdx; // First index into WriteProcResTable.
121   uint16_t NumWriteProcResEntries;
122   uint16_t WriteLatencyIdx; // First index into WriteLatencyTable.
123   uint16_t NumWriteLatencyEntries;
124   uint16_t ReadAdvanceIdx; // First index into ReadAdvanceTable.
125   uint16_t NumReadAdvanceEntries;
126 
127   bool isValid() const {
128     return NumMicroOps != InvalidNumMicroOps;
129   }
130   bool isVariant() const {
131     return NumMicroOps == VariantNumMicroOps;
132   }
133 };
134 
135 /// Specify the cost of a register definition in terms of number of physical
136 /// register allocated at register renaming stage. For example, AMD Jaguar.
137 /// natively supports 128-bit data types, and operations on 256-bit registers
138 /// (i.e. YMM registers) are internally split into two COPs (complex operations)
139 /// and each COP updates a physical register. Basically, on Jaguar, a YMM
140 /// register write effectively consumes two physical registers. That means,
141 /// the cost of a YMM write in the BtVer2 model is 2.
142 struct MCRegisterCostEntry {
143   unsigned RegisterClassID;
144   unsigned Cost;
145   bool AllowMoveElimination;
146 };
147 
148 /// A register file descriptor.
149 ///
150 /// This struct allows to describe processor register files. In particular, it
151 /// helps describing the size of the register file, as well as the cost of
152 /// allocating a register file at register renaming stage.
153 /// FIXME: this struct can be extended to provide information about the number
154 /// of read/write ports to the register file.  A value of zero for field
155 /// 'NumPhysRegs' means: this register file has an unbounded number of physical
156 /// registers.
157 struct MCRegisterFileDesc {
158   const char *Name;
159   uint16_t NumPhysRegs;
160   uint16_t NumRegisterCostEntries;
161   // Index of the first cost entry in MCExtraProcessorInfo::RegisterCostTable.
162   uint16_t RegisterCostEntryIdx;
163   // A value of zero means: there is no limit in the number of moves that can be
164   // eliminated every cycle.
165   uint16_t MaxMovesEliminatedPerCycle;
166   // Ture if this register file only knows how to optimize register moves from
167   // known zero registers.
168   bool AllowZeroMoveEliminationOnly;
169 };
170 
171 /// Provide extra details about the machine processor.
172 ///
173 /// This is a collection of "optional" processor information that is not
174 /// normally used by the LLVM machine schedulers, but that can be consumed by
175 /// external tools like llvm-mca to improve the quality of the peformance
176 /// analysis.
177 struct MCExtraProcessorInfo {
178   // Actual size of the reorder buffer in hardware.
179   unsigned ReorderBufferSize;
180   // Number of instructions retired per cycle.
181   unsigned MaxRetirePerCycle;
182   const MCRegisterFileDesc *RegisterFiles;
183   unsigned NumRegisterFiles;
184   const MCRegisterCostEntry *RegisterCostTable;
185   unsigned NumRegisterCostEntries;
186   unsigned LoadQueueID;
187   unsigned StoreQueueID;
188 };
189 
190 /// Machine model for scheduling, bundling, and heuristics.
191 ///
192 /// The machine model directly provides basic information about the
193 /// microarchitecture to the scheduler in the form of properties. It also
194 /// optionally refers to scheduler resource tables and itinerary
195 /// tables. Scheduler resource tables model the latency and cost for each
196 /// instruction type. Itinerary tables are an independent mechanism that
197 /// provides a detailed reservation table describing each cycle of instruction
198 /// execution. Subtargets may define any or all of the above categories of data
199 /// depending on the type of CPU and selected scheduler.
200 ///
201 /// The machine independent properties defined here are used by the scheduler as
202 /// an abstract machine model. A real micro-architecture has a number of
203 /// buffers, queues, and stages. Declaring that a given machine-independent
204 /// abstract property corresponds to a specific physical property across all
205 /// subtargets can't be done. Nonetheless, the abstract model is
206 /// useful. Futhermore, subtargets typically extend this model with processor
207 /// specific resources to model any hardware features that can be exploited by
208 /// scheduling heuristics and aren't sufficiently represented in the abstract.
209 ///
210 /// The abstract pipeline is built around the notion of an "issue point". This
211 /// is merely a reference point for counting machine cycles. The physical
212 /// machine will have pipeline stages that delay execution. The scheduler does
213 /// not model those delays because they are irrelevant as long as they are
214 /// consistent. Inaccuracies arise when instructions have different execution
215 /// delays relative to each other, in addition to their intrinsic latency. Those
216 /// special cases can be handled by TableGen constructs such as, ReadAdvance,
217 /// which reduces latency when reading data, and ResourceCycles, which consumes
218 /// a processor resource when writing data for a number of abstract
219 /// cycles.
220 ///
221 /// TODO: One tool currently missing is the ability to add a delay to
222 /// ResourceCycles. That would be easy to add and would likely cover all cases
223 /// currently handled by the legacy itinerary tables.
224 ///
225 /// A note on out-of-order execution and, more generally, instruction
226 /// buffers. Part of the CPU pipeline is always in-order. The issue point, which
227 /// is the point of reference for counting cycles, only makes sense as an
228 /// in-order part of the pipeline. Other parts of the pipeline are sometimes
229 /// falling behind and sometimes catching up. It's only interesting to model
230 /// those other, decoupled parts of the pipeline if they may be predictably
231 /// resource constrained in a way that the scheduler can exploit.
232 ///
233 /// The LLVM machine model distinguishes between in-order constraints and
234 /// out-of-order constraints so that the target's scheduling strategy can apply
235 /// appropriate heuristics. For a well-balanced CPU pipeline, out-of-order
236 /// resources would not typically be treated as a hard scheduling
237 /// constraint. For example, in the GenericScheduler, a delay caused by limited
238 /// out-of-order resources is not directly reflected in the number of cycles
239 /// that the scheduler sees between issuing an instruction and its dependent
240 /// instructions. In other words, out-of-order resources don't directly increase
241 /// the latency between pairs of instructions. However, they can still be used
242 /// to detect potential bottlenecks across a sequence of instructions and bias
243 /// the scheduling heuristics appropriately.
244 struct MCSchedModel {
245   // IssueWidth is the maximum number of instructions that may be scheduled in
246   // the same per-cycle group. This is meant to be a hard in-order constraint
247   // (a.k.a. "hazard"). In the GenericScheduler strategy, no more than
248   // IssueWidth micro-ops can ever be scheduled in a particular cycle.
249   //
250   // In practice, IssueWidth is useful to model any bottleneck between the
251   // decoder (after micro-op expansion) and the out-of-order reservation
252   // stations or the decoder bandwidth itself. If the total number of
253   // reservation stations is also a bottleneck, or if any other pipeline stage
254   // has a bandwidth limitation, then that can be naturally modeled by adding an
255   // out-of-order processor resource.
256   unsigned IssueWidth;
257   static const unsigned DefaultIssueWidth = 1;
258 
259   // MicroOpBufferSize is the number of micro-ops that the processor may buffer
260   // for out-of-order execution.
261   //
262   // "0" means operations that are not ready in this cycle are not considered
263   // for scheduling (they go in the pending queue). Latency is paramount. This
264   // may be more efficient if many instructions are pending in a schedule.
265   //
266   // "1" means all instructions are considered for scheduling regardless of
267   // whether they are ready in this cycle. Latency still causes issue stalls,
268   // but we balance those stalls against other heuristics.
269   //
270   // "> 1" means the processor is out-of-order. This is a machine independent
271   // estimate of highly machine specific characteristics such as the register
272   // renaming pool and reorder buffer.
273   unsigned MicroOpBufferSize;
274   static const unsigned DefaultMicroOpBufferSize = 0;
275 
276   // LoopMicroOpBufferSize is the number of micro-ops that the processor may
277   // buffer for optimized loop execution. More generally, this represents the
278   // optimal number of micro-ops in a loop body. A loop may be partially
279   // unrolled to bring the count of micro-ops in the loop body closer to this
280   // number.
281   unsigned LoopMicroOpBufferSize;
282   static const unsigned DefaultLoopMicroOpBufferSize = 0;
283 
284   // LoadLatency is the expected latency of load instructions.
285   unsigned LoadLatency;
286   static const unsigned DefaultLoadLatency = 4;
287 
288   // HighLatency is the expected latency of "very high latency" operations.
289   // See TargetInstrInfo::isHighLatencyDef().
290   // By default, this is set to an arbitrarily high number of cycles
291   // likely to have some impact on scheduling heuristics.
292   unsigned HighLatency;
293   static const unsigned DefaultHighLatency = 10;
294 
295   // MispredictPenalty is the typical number of extra cycles the processor
296   // takes to recover from a branch misprediction.
297   unsigned MispredictPenalty;
298   static const unsigned DefaultMispredictPenalty = 10;
299 
300   bool PostRAScheduler; // default value is false
301 
302   bool CompleteModel;
303 
304   unsigned ProcID;
305   const MCProcResourceDesc *ProcResourceTable;
306   const MCSchedClassDesc *SchedClassTable;
307   unsigned NumProcResourceKinds;
308   unsigned NumSchedClasses;
309   // Instruction itinerary tables used by InstrItineraryData.
310   friend class InstrItineraryData;
311   const InstrItinerary *InstrItineraries;
312 
313   const MCExtraProcessorInfo *ExtraProcessorInfo;
314 
315   bool hasExtraProcessorInfo() const { return ExtraProcessorInfo; }
316 
317   unsigned getProcessorID() const { return ProcID; }
318 
319   /// Does this machine model include instruction-level scheduling.
320   bool hasInstrSchedModel() const { return SchedClassTable; }
321 
322   const MCExtraProcessorInfo &getExtraProcessorInfo() const {
323     assert(hasExtraProcessorInfo() &&
324            "No extra information available for this model");
325     return *ExtraProcessorInfo;
326   }
327 
328   /// Return true if this machine model data for all instructions with a
329   /// scheduling class (itinerary class or SchedRW list).
330   bool isComplete() const { return CompleteModel; }
331 
332   /// Return true if machine supports out of order execution.
333   bool isOutOfOrder() const { return MicroOpBufferSize > 1; }
334 
335   unsigned getNumProcResourceKinds() const {
336     return NumProcResourceKinds;
337   }
338 
339   const MCProcResourceDesc *getProcResource(unsigned ProcResourceIdx) const {
340     assert(hasInstrSchedModel() && "No scheduling machine model");
341 
342     assert(ProcResourceIdx < NumProcResourceKinds && "bad proc resource idx");
343     return &ProcResourceTable[ProcResourceIdx];
344   }
345 
346   const MCSchedClassDesc *getSchedClassDesc(unsigned SchedClassIdx) const {
347     assert(hasInstrSchedModel() && "No scheduling machine model");
348 
349     assert(SchedClassIdx < NumSchedClasses && "bad scheduling class idx");
350     return &SchedClassTable[SchedClassIdx];
351   }
352 
353   /// Returns the latency value for the scheduling class.
354   static int computeInstrLatency(const MCSubtargetInfo &STI,
355                                  const MCSchedClassDesc &SCDesc);
356 
357   int computeInstrLatency(const MCSubtargetInfo &STI, unsigned SClass) const;
358   int computeInstrLatency(const MCSubtargetInfo &STI, const MCInstrInfo &MCII,
359                           const MCInst &Inst) const;
360 
361   // Returns the reciprocal throughput information from a MCSchedClassDesc.
362   static double
363   getReciprocalThroughput(const MCSubtargetInfo &STI,
364                           const MCSchedClassDesc &SCDesc);
365 
366   static double
367   getReciprocalThroughput(unsigned SchedClass, const InstrItineraryData &IID);
368 
369   double
370   getReciprocalThroughput(const MCSubtargetInfo &STI, const MCInstrInfo &MCII,
371                           const MCInst &Inst) const;
372 
373   /// Returns the maximum forwarding delay for register reads dependent on
374   /// writes of scheduling class WriteResourceIdx.
375   static unsigned getForwardingDelayCycles(ArrayRef<MCReadAdvanceEntry> Entries,
376                                            unsigned WriteResourceIdx = 0);
377 
378   /// Returns the default initialized model.
379   static const MCSchedModel &GetDefaultSchedModel() { return Default; }
380   static const MCSchedModel Default;
381 };
382 
383 } // namespace llvm
384 
385 #endif
386