1 //===- TargetSchedule.td - Target Independent Scheduling ---*- tablegen -*-===//
3 // The LLVM Compiler Infrastructure
5 // This file is distributed under the University of Illinois Open Source
6 // License. See LICENSE.TXT for details.
8 //===----------------------------------------------------------------------===//
10 // This file defines the target-independent scheduling interfaces which should
11 // be implemented by each target which is using TableGen based scheduling.
13 // The SchedMachineModel is defined by subtargets for three categories of data:
14 // 1. Basic properties for coarse grained instruction cost model.
15 // 2. Scheduler Read/Write resources for simple per-opcode cost model.
16 // 3. Instruction itineraries for detailed reservation tables.
18 // (1) Basic properties are defined by the SchedMachineModel
19 // class. Target hooks allow subtargets to associate opcodes with
22 // (2) A per-operand machine model can be implemented in any
23 // combination of the following ways:
25 // A. Associate per-operand SchedReadWrite types with Instructions by
26 // modifying the Instruction definition to inherit from Sched. For
27 // each subtarget, define WriteRes and ReadAdvance to associate
28 // processor resources and latency with each SchedReadWrite type.
30 // B. In each instruction definition, name an ItineraryClass. For each
31 // subtarget, define ItinRW entries to map ItineraryClass to
32 // per-operand SchedReadWrite types. Unlike method A, these types may
33 // be subtarget specific and can be directly associated with resources
34 // by defining SchedWriteRes and SchedReadAdvance.
36 // C. In the subtarget, map SchedReadWrite types to specific
37 // opcodes. This overrides any SchedReadWrite types or
38 // ItineraryClasses defined by the Instruction. As in method B, the
39 // subtarget can directly associate resources with SchedReadWrite
40 // types by defining SchedWriteRes and SchedReadAdvance.
42 // D. In either the target or subtarget, define SchedWriteVariant or
43 // SchedReadVariant to map one SchedReadWrite type onto another
44 // sequence of SchedReadWrite types. This allows dynamic selection of
45 // an instruction's machine model via custom C++ code. It also allows
46 // a machine-independent SchedReadWrite type to map to a sequence of
47 // machine-dependent types.
49 // (3) A per-pipeline-stage machine model can be implemented by providing
50 // Itineraries in addition to mapping instructions to ItineraryClasses.
51 //===----------------------------------------------------------------------===//
53 // Include legacy support for instruction itineraries.
54 include "llvm/Target/TargetItinerary.td"
56 class Instruction; // Forward def
58 class Predicate; // Forward def
60 // DAG operator that interprets the DAG args as Instruction defs.
63 // DAG operator that interprets each DAG arg as a regex pattern for
64 // matching Instruction opcode names.
65 // The regex must match the beginning of the opcode (as in Python re.match).
66 // To avoid matching prefixes, append '$' to the pattern.
69 // Define the SchedMachineModel and provide basic properties for
70 // coarse grained instruction cost model. Default values for the
71 // properties are defined in MCSchedModel. A value of "-1" in the
72 // target description's SchedMachineModel indicates that the property
73 // is not overriden by the target.
75 // Target hooks allow subtargets to associate LoadLatency and
76 // HighLatency with groups of opcodes.
78 // See MCSchedule.h for detailed comments.
79 class SchedMachineModel {
80 int IssueWidth = -1; // Max micro-ops that may be scheduled per cycle.
81 int MicroOpBufferSize = -1; // Max micro-ops that can be buffered.
82 int LoopMicroOpBufferSize = -1; // Max micro-ops that can be buffered for
83 // optimized loop dispatch/execution.
84 int LoadLatency = -1; // Cycles for loads to access the cache.
85 int HighLatency = -1; // Approximation of cycles for "high latency" ops.
86 int MispredictPenalty = -1; // Extra cycles for a mispredicted branch.
88 // Per-cycle resources tables.
89 ProcessorItineraries Itineraries = NoItineraries;
91 bit PostRAScheduler = 0; // Enable Post RegAlloc Scheduler pass.
93 // Subtargets that define a model for only a subset of instructions
94 // that have a scheduling class (itinerary class or SchedRW list)
95 // and may actually be generated for that subtarget must clear this
96 // bit. Otherwise, the scheduler considers an unmodelled opcode to
97 // be an error. This should only be set during initial bringup,
98 // or there will be no way to catch simple errors in the model
99 // resulting from changes to the instruction definitions.
100 bit CompleteModel = 1;
102 // Indicates that we should do full overlap checking for multiple InstrRWs
103 // definining the same instructions within the same SchedMachineModel.
104 // FIXME: Remove when all in tree targets are clean with the full check
106 bit FullInstRWOverlapCheck = 1;
108 // A processor may only implement part of published ISA, due to either new ISA
109 // extensions, (e.g. Pentium 4 doesn't have AVX) or implementation
110 // (ARM/MIPS/PowerPC/SPARC soft float cores).
112 // For a processor which doesn't support some feature(s), the schedule model
115 // let<Predicate> UnsupportedFeatures = [HaveA,..,HaveY];
117 // to skip the checks for scheduling information when building LLVM for
118 // instructions which have any of the listed predicates in their Predicates
120 list<Predicate> UnsupportedFeatures = [];
122 bit NoModel = 0; // Special tag to indicate missing machine model.
125 def NoSchedModel : SchedMachineModel {
127 let CompleteModel = 0;
130 // Define a kind of processor resource that may be common across
131 // similar subtargets.
132 class ProcResourceKind;
134 // Define a number of interchangeable processor resources. NumUnits
135 // determines the throughput of instructions that require the resource.
137 // An optional Super resource may be given to model these resources as
138 // a subset of the more general super resources. Using one of these
139 // resources implies using one of the super resoruces.
141 // ProcResourceUnits normally model a few buffered resources within an
142 // out-of-order engine. Buffered resources may be held for multiple
143 // clock cycles, but the scheduler does not pin them to a particular
144 // clock cycle relative to instruction dispatch. Setting BufferSize=0
145 // changes this to an in-order issue/dispatch resource. In this case,
146 // the scheduler counts down from the cycle that the instruction
147 // issues in-order, forcing a stall whenever a subsequent instruction
148 // requires the same resource until the number of ResourceCycles
149 // specified in WriteRes expire. Setting BufferSize=1 changes this to
150 // an in-order latency resource. In this case, the scheduler models
151 // producer/consumer stalls between instructions that use the
154 // Examples (all assume an out-of-order engine):
156 // Use BufferSize = -1 for "issue ports" fed by a unified reservation
157 // station. Here the size of the reservation station is modeled by
158 // MicroOpBufferSize, which should be the minimum size of either the
159 // register rename pool, unified reservation station, or reorder
162 // Use BufferSize = 0 for resources that force "dispatch/issue
163 // groups". (Different processors define dispath/issue
164 // differently. Here we refer to stage between decoding into micro-ops
165 // and moving them into a reservation station.) Normally NumMicroOps
166 // is sufficient to limit dispatch/issue groups. However, some
167 // processors can form groups of with only certain combinitions of
168 // instruction types. e.g. POWER7.
170 // Use BufferSize = 1 for in-order execution units. This is used for
171 // an in-order pipeline within an out-of-order core where scheduling
172 // dependent operations back-to-back is guaranteed to cause a
173 // bubble. e.g. Cortex-a9 floating-point.
175 // Use BufferSize > 1 for out-of-order executions units with a
176 // separate reservation station. This simply models the size of the
177 // reservation station.
179 // To model both dispatch/issue groups and in-order execution units,
180 // create two types of units, one with BufferSize=0 and one with
183 // SchedModel ties these units to a processor for any stand-alone defs
185 class ProcResourceUnits<ProcResourceKind kind, int num,
186 list<string> pfmCounters> {
187 ProcResourceKind Kind = kind;
189 ProcResourceKind Super = ?;
191 SchedMachineModel SchedModel = ?;
194 // EponymousProcResourceKind helps implement ProcResourceUnits by
195 // allowing a ProcResourceUnits definition to reference itself. It
196 // should not be referenced anywhere else.
197 def EponymousProcResourceKind : ProcResourceKind;
199 // Subtargets typically define processor resource kind and number of
200 // units in one place.
201 class ProcResource<int num, list<string> pfmCounters = []> : ProcResourceKind,
202 ProcResourceUnits<EponymousProcResourceKind, num, pfmCounters>;
204 class ProcResGroup<list<ProcResource> resources> : ProcResourceKind {
205 list<ProcResource> Resources = resources;
206 SchedMachineModel SchedModel = ?;
210 // A target architecture may define SchedReadWrite types and associate
211 // them with instruction operands.
212 class SchedReadWrite;
214 // List the per-operand types that map to the machine model of an
215 // instruction. One SchedWrite type must be listed for each explicit
216 // def operand in order. Additional SchedWrite types may optionally be
217 // listed for implicit def operands. SchedRead types may optionally
218 // be listed for use operands in order. The order of defs relative to
219 // uses is insignificant. This way, the same SchedReadWrite list may
220 // be used for multiple forms of an operation. For example, a
221 // two-address instruction could have two tied operands or single
222 // operand that both reads and writes a reg. In both cases we have a
223 // single SchedWrite and single SchedRead in any order.
224 class Sched<list<SchedReadWrite> schedrw> {
225 list<SchedReadWrite> SchedRW = schedrw;
228 // Define a scheduler resource associated with a def operand.
229 class SchedWrite : SchedReadWrite;
230 def NoWrite : SchedWrite;
232 // Define a scheduler resource associated with a use operand.
233 class SchedRead : SchedReadWrite;
235 // Define a SchedWrite that is modeled as a sequence of other
236 // SchedWrites with additive latency. This allows a single operand to
237 // be mapped the resources composed from a set of previously defined
240 // If the final write in this sequence is a SchedWriteVariant marked
241 // Variadic, then the list of prior writes are distributed across all
242 // operands after resolving the predicate for the final write.
244 // SchedModel silences warnings but is ignored.
245 class WriteSequence<list<SchedWrite> writes, int rep = 1> : SchedWrite {
246 list<SchedWrite> Writes = writes;
248 SchedMachineModel SchedModel = ?;
251 // Define values common to WriteRes and SchedWriteRes.
253 // SchedModel ties these resources to a processor.
254 class ProcWriteResources<list<ProcResourceKind> resources> {
255 list<ProcResourceKind> ProcResources = resources;
256 list<int> ResourceCycles = [];
261 // Allow a processor to mark some scheduling classes as unsupported
262 // for stronger verification.
264 // Allow a processor to mark some scheduling classes as single-issue.
265 // SingleIssue is an alias for Begin/End Group.
267 SchedMachineModel SchedModel = ?;
270 // Define the resources and latency of a SchedWrite. This will be used
271 // directly by targets that have no itinerary classes. In this case,
272 // SchedWrite is defined by the target, while WriteResources is
273 // defined by the subtarget, and maps the SchedWrite to processor
276 // If a target already has itinerary classes, SchedWriteResources can
277 // be used instead to define subtarget specific SchedWrites and map
278 // them to processor resources in one place. Then ItinRW can map
279 // itinerary classes to the subtarget's SchedWrites.
281 // ProcResources indicates the set of resources consumed by the write.
282 // Optionally, ResourceCycles indicates the number of cycles the
283 // resource is consumed. Each ResourceCycles item is paired with the
284 // ProcResource item at the same position in its list. ResourceCycles
285 // can be `[]`: in that case, all resources are consumed for a single
286 // cycle, regardless of latency, which models a fully pipelined processing
287 // unit. A value of 0 for ResourceCycles means that the resource must
288 // be available but is not consumed, which is only relevant for
289 // unbuffered resources.
291 // By default, each SchedWrite takes one micro-op, which is counted
292 // against the processor's IssueWidth limit. If an instruction can
293 // write multiple registers with a single micro-op, the subtarget
294 // should define one of the writes to be zero micro-ops. If a
295 // subtarget requires multiple micro-ops to write a single result, it
296 // should either override the write's NumMicroOps to be greater than 1
297 // or require additional writes. Extra writes can be required either
298 // by defining a WriteSequence, or simply listing extra writes in the
299 // instruction's list of writers beyond the number of "def"
300 // operands. The scheduler assumes that all micro-ops must be
301 // dispatched in the same cycle. These micro-ops may be required to
302 // begin or end the current dispatch group.
303 class WriteRes<SchedWrite write, list<ProcResourceKind> resources>
304 : ProcWriteResources<resources> {
305 SchedWrite WriteType = write;
308 // Directly name a set of WriteResources defining a new SchedWrite
309 // type at the same time. This class is unaware of its SchedModel so
310 // must be referenced by InstRW or ItinRW.
311 class SchedWriteRes<list<ProcResourceKind> resources> : SchedWrite,
312 ProcWriteResources<resources>;
314 // Define values common to ReadAdvance and SchedReadAdvance.
316 // SchedModel ties these resources to a processor.
317 class ProcReadAdvance<int cycles, list<SchedWrite> writes = []> {
319 list<SchedWrite> ValidWrites = writes;
320 // Allow a processor to mark some scheduling classes as unsupported
321 // for stronger verification.
323 SchedMachineModel SchedModel = ?;
326 // A processor may define a ReadAdvance associated with a SchedRead
327 // to reduce latency of a prior write by N cycles. A negative advance
328 // effectively increases latency, which may be used for cross-domain
331 // A ReadAdvance may be associated with a list of SchedWrites
332 // to implement pipeline bypass. The Writes list may be empty to
333 // indicate operands that are always read this number of Cycles later
334 // than a normal register read, allowing the read's parent instruction
335 // to issue earlier relative to the writer.
336 class ReadAdvance<SchedRead read, int cycles, list<SchedWrite> writes = []>
337 : ProcReadAdvance<cycles, writes> {
338 SchedRead ReadType = read;
341 // Directly associate a new SchedRead type with a delay and optional
342 // pipeline bypass. For use with InstRW or ItinRW.
343 class SchedReadAdvance<int cycles, list<SchedWrite> writes = []> : SchedRead,
344 ProcReadAdvance<cycles, writes>;
346 // Define SchedRead defaults. Reads seldom need special treatment.
347 def ReadDefault : SchedRead;
348 def NoReadAdvance : SchedReadAdvance<0>;
350 // Define shared code that will be in the same scope as all
351 // SchedPredicates. Available variables are:
352 // (const MachineInstr *MI, const TargetSchedModel *SchedModel)
353 class PredicateProlog<code c> {
357 // Base class for scheduling predicates.
358 class SchedPredicateBase;
360 // A scheduling predicate whose logic is defined by a MCInstPredicate.
361 // This can directly be used by SchedWriteVariant definitions.
362 class MCSchedPredicate<MCInstPredicate P> : SchedPredicateBase {
363 MCInstPredicate Pred = P;
364 SchedMachineModel SchedModel = ?;
367 // Define a predicate to determine which SchedVariant applies to a
368 // particular MachineInstr. The code snippet is used as an
369 // if-statement's expression. Available variables are MI, SchedModel,
370 // and anything defined in a PredicateProlog.
372 // SchedModel silences warnings but is ignored.
373 class SchedPredicate<code pred> : SchedPredicateBase {
374 SchedMachineModel SchedModel = ?;
375 code Predicate = pred;
377 def NoSchedPred : SchedPredicate<[{true}]>;
379 // Associate a predicate with a list of SchedReadWrites. By default,
380 // the selected SchedReadWrites are still associated with a single
381 // operand and assumed to execute sequentially with additive
382 // latency. However, if the parent SchedWriteVariant or
383 // SchedReadVariant is marked "Variadic", then each Selected
384 // SchedReadWrite is mapped in place to the instruction's variadic
385 // operands. In this case, latency is not additive. If the current Variant
386 // is already part of a Sequence, then that entire chain leading up to
387 // the Variant is distributed over the variadic operands.
388 class SchedVar<SchedPredicateBase pred, list<SchedReadWrite> selected> {
389 SchedPredicateBase Predicate = pred;
390 list<SchedReadWrite> Selected = selected;
393 // SchedModel silences warnings but is ignored.
394 class SchedVariant<list<SchedVar> variants> {
395 list<SchedVar> Variants = variants;
397 SchedMachineModel SchedModel = ?;
400 // A SchedWriteVariant is a single SchedWrite type that maps to a list
401 // of SchedWrite types under the conditions defined by its predicates.
403 // A Variadic write is expanded to cover multiple "def" operands. The
404 // SchedVariant's Expansion list is then interpreted as one write
405 // per-operand instead of the usual sequential writes feeding a single
407 class SchedWriteVariant<list<SchedVar> variants> : SchedWrite,
408 SchedVariant<variants> {
411 // A SchedReadVariant is a single SchedRead type that maps to a list
412 // of SchedRead types under the conditions defined by its predicates.
414 // A Variadic write is expanded to cover multiple "readsReg" operands as
416 class SchedReadVariant<list<SchedVar> variants> : SchedRead,
417 SchedVariant<variants> {
420 // Map a set of opcodes to a list of SchedReadWrite types. This allows
421 // the subtarget to easily override specific operations.
423 // SchedModel ties this opcode mapping to a processor.
424 class InstRW<list<SchedReadWrite> rw, dag instrlist> {
425 list<SchedReadWrite> OperandReadWrites = rw;
426 dag Instrs = instrlist;
427 SchedMachineModel SchedModel = ?;
428 // Allow a subtarget to mark some instructions as unsupported.
432 // Map a set of itinerary classes to SchedReadWrite resources. This is
433 // used to bootstrap a target (e.g. ARM) when itineraries already
434 // exist and changing InstrInfo is undesirable.
436 // SchedModel ties this ItineraryClass mapping to a processor.
437 class ItinRW<list<SchedReadWrite> rw, list<InstrItinClass> iic> {
438 list<InstrItinClass> MatchedItinClasses = iic;
439 list<SchedReadWrite> OperandReadWrites = rw;
440 SchedMachineModel SchedModel = ?;
443 // Alias a target-defined SchedReadWrite to a processor specific
444 // SchedReadWrite. This allows a subtarget to easily map a
445 // SchedReadWrite type onto a WriteSequence, SchedWriteVariant, or
448 // SchedModel will usually be provided by surrounding let statement
449 // and ties this SchedAlias mapping to a processor.
450 class SchedAlias<SchedReadWrite match, SchedReadWrite alias> {
451 SchedReadWrite MatchRW = match;
452 SchedReadWrite AliasRW = alias;
453 SchedMachineModel SchedModel = ?;
456 // Allow the definition of processor register files for register renaming
459 // Each processor register file declares:
460 // - The set of registers that can be renamed.
461 // - The number of physical registers which can be used for register renaming
463 // - The cost of a register rename.
465 // The cost of a rename is the number of physical registers allocated by the
466 // register alias table to map the new definition. By default, register can be
467 // renamed at the cost of a single physical register. Note that register costs
468 // are defined at register class granularity (see field `Costs`).
470 // The set of registers that are subject to register renaming is declared using
471 // a list of register classes (see field `RegClasses`). An empty list of
472 // register classes means: all the logical registers defined by the target can
475 // A register R can be renamed if its register class appears in the `RegClasses`
476 // set. When R is written, a new alias is allocated at the cost of one or more
477 // physical registers; as a result, false dependencies on R are removed.
479 // A sub-register V of register R is implicitly part of the same register file.
480 // However, V is only renamed if its register class is part of `RegClasses`.
481 // Otherwise, the processor keeps it (as well as any other different part
482 // of R) together with R, and a write of V always causes a compulsory read of R.
484 // This is what happens for example on AMD processors (at least from Bulldozer
485 // onwards), where AL and AH are not treated as independent from AX, and AX is
486 // not treated as independent from EAX. A write to AL has an implicity false
487 // dependency on the last write to EAX (or a portion of EAX). As a consequence,
488 // a write to AL cannot go in parallel with a write to AH.
490 // There is no false dependency if the partial register write belongs to a
491 // register class that is in `RegClasses`.
492 // There is also no penalty for writes that "clear the content a super-register"
493 // (see MC/MCInstrAnalysis.h - method MCInstrAnalysis::clearsSuperRegisters()).
494 // On x86-64, 32-bit GPR writes implicitly zero the upper half of the underlying
495 // physical register, effectively removing any false dependencies with the
496 // previous register definition.
498 // TODO: This implementation assumes that there is no limit in the number of
499 // renames per cycle, which might not be true for all hardware or register
500 // classes. Also, there is no limit to how many times the same logical register
501 // can be renamed during the same cycle.
503 // TODO: we don't currently model merge penalties for the case where a write to
504 // a part of a register is followed by a read from a larger part of the same
505 // register. On some Intel chips, different parts of a GPR can be stored in
506 // different physical registers. However, there is a cost to pay for when the
507 // partial write is combined with the previous super-register definition. We
508 // should add support for these cases, and correctly model merge problems with
509 // partial register accesses.
510 class RegisterFile<int numPhysRegs, list<RegisterClass> Classes = [],
511 list<int> Costs = []> {
512 list<RegisterClass> RegClasses = Classes;
513 list<int> RegCosts = Costs;
514 int NumPhysRegs = numPhysRegs;
515 SchedMachineModel SchedModel = ?;
518 // Describe the retire control unit.
519 // A retire control unit specifies the size of the reorder buffer, as well as
520 // the maximum number of opcodes that can be retired every cycle.
521 // A value less-than-or-equal-to zero for field 'ReorderBufferSize' means: "the
522 // size is unknown". The idea is that external tools can fall-back to using
523 // field MicroOpBufferSize in SchedModel if the reorder buffer size is unknown.
524 // A zero or negative value for field 'MaxRetirePerCycle' means "no
525 // restrictions on the number of instructions retired per cycle".
526 // Models can optionally specify up to one instance of RetireControlUnit per
528 class RetireControlUnit<int bufferSize, int retirePerCycle> {
529 int ReorderBufferSize = bufferSize;
530 int MaxRetirePerCycle = retirePerCycle;
531 SchedMachineModel SchedModel = ?;
534 // Allow the definition of hardware counters.
536 SchedMachineModel SchedModel = ?;
539 // Each processor can define how to measure cycles by defining a
541 class PfmCycleCounter<string counter> : PfmCounter {
542 string Counter = counter;
545 // Each ProcResourceUnits can define how to measure issued uops by defining
546 // a PfmIssueCounter.
547 class PfmIssueCounter<ProcResourceUnits resource, list<string> counters>
549 // The resource units on which uops are issued.
550 ProcResourceUnits Resource = resource;
551 // The list of counters that measure issue events.
552 list<string> Counters = counters;