Home | History | Annotate | Download | only in Target
      1 //===- TargetSchedule.td - Target Independent Scheduling ---*- tablegen -*-===//
      2 //
      3 //                     The LLVM Compiler Infrastructure
      4 //
      5 // This file is distributed under the University of Illinois Open Source
      6 // License. See LICENSE.TXT for details.
      7 //
      8 //===----------------------------------------------------------------------===//
      9 //
     10 // This file defines the target-independent scheduling interfaces which should
     11 // be implemented by each target which is using TableGen based scheduling.
     12 //
     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.
     17 //
     18 // (1) Basic properties are defined by the SchedMachineModel
     19 // class. Target hooks allow subtargets to associate opcodes with
     20 // those properties.
     21 //
     22 // (2) A per-operand machine model can be implemented in any
     23 // combination of the following ways:
     24 //
     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.
     29 //
     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.
     35 //
     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.
     41 //
     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.
     48 //
     49 // (3) A per-pipeline-stage machine model can be implemented by providing
     50 // Itineraries in addition to mapping instructions to ItineraryClasses.
     51 //===----------------------------------------------------------------------===//
     52 
     53 // Include legacy support for instruction itineraries.
     54 include "llvm/Target/TargetItinerary.td"
     55 
     56 class Instruction; // Forward def
     57 
     58 class Predicate; // Forward def
     59 
     60 // DAG operator that interprets the DAG args as Instruction defs.
     61 def instrs;
     62 
     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.
     67 def instregex;
     68 
     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.
     74 //
     75 // Target hooks allow subtargets to associate LoadLatency and
     76 // HighLatency with groups of opcodes.
     77 //
     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.
     87 
     88   // Per-cycle resources tables.
     89   ProcessorItineraries Itineraries = NoItineraries;
     90 
     91   bit PostRAScheduler = 0; // Enable Post RegAlloc Scheduler pass.
     92 
     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;
    101 
    102   // A processor may only implement part of published ISA, due to either new ISA
    103   // extensions, (e.g. Pentium 4 doesn't have AVX) or implementation
    104   // (ARM/MIPS/PowerPC/SPARC soft float cores).
    105   //
    106   // For a processor which doesn't support some feature(s), the schedule model
    107   // can use:
    108   //
    109   // let<Predicate> UnsupportedFeatures = [HaveA,..,HaveY];
    110   //
    111   // to skip the checks for scheduling information when building LLVM for
    112   // instructions which have any of the listed predicates in their Predicates
    113   // field.
    114   list<Predicate> UnsupportedFeatures = [];
    115 
    116   bit NoModel = 0; // Special tag to indicate missing machine model.
    117 }
    118 
    119 def NoSchedModel : SchedMachineModel {
    120   let NoModel = 1;
    121   let CompleteModel = 0;
    122 }
    123 
    124 // Define a kind of processor resource that may be common across
    125 // similar subtargets.
    126 class ProcResourceKind;
    127 
    128 // Define a number of interchangeable processor resources. NumUnits
    129 // determines the throughput of instructions that require the resource.
    130 //
    131 // An optional Super resource may be given to model these resources as
    132 // a subset of the more general super resources. Using one of these
    133 // resources implies using one of the super resoruces.
    134 //
    135 // ProcResourceUnits normally model a few buffered resources within an
    136 // out-of-order engine. Buffered resources may be held for multiple
    137 // clock cycles, but the scheduler does not pin them to a particular
    138 // clock cycle relative to instruction dispatch. Setting BufferSize=0
    139 // changes this to an in-order issue/dispatch resource. In this case,
    140 // the scheduler counts down from the cycle that the instruction
    141 // issues in-order, forcing a stall whenever a subsequent instruction
    142 // requires the same resource until the number of ResourceCycles
    143 // specified in WriteRes expire. Setting BufferSize=1 changes this to
    144 // an in-order latency resource. In this case, the scheduler models
    145 // producer/consumer stalls between instructions that use the
    146 // resource.
    147 //
    148 // Examples (all assume an out-of-order engine):
    149 //
    150 // Use BufferSize = -1 for "issue ports" fed by a unified reservation
    151 // station. Here the size of the reservation station is modeled by
    152 // MicroOpBufferSize, which should be the minimum size of either the
    153 // register rename pool, unified reservation station, or reorder
    154 // buffer.
    155 //
    156 // Use BufferSize = 0 for resources that force "dispatch/issue
    157 // groups". (Different processors define dispath/issue
    158 // differently. Here we refer to stage between decoding into micro-ops
    159 // and moving them into a reservation station.) Normally NumMicroOps
    160 // is sufficient to limit dispatch/issue groups. However, some
    161 // processors can form groups of with only certain combinitions of
    162 // instruction types. e.g. POWER7.
    163 //
    164 // Use BufferSize = 1 for in-order execution units. This is used for
    165 // an in-order pipeline within an out-of-order core where scheduling
    166 // dependent operations back-to-back is guaranteed to cause a
    167 // bubble. e.g. Cortex-a9 floating-point.
    168 //
    169 // Use BufferSize > 1 for out-of-order executions units with a
    170 // separate reservation station. This simply models the size of the
    171 // reservation station.
    172 //
    173 // To model both dispatch/issue groups and in-order execution units,
    174 // create two types of units, one with BufferSize=0 and one with
    175 // BufferSize=1.
    176 //
    177 // SchedModel ties these units to a processor for any stand-alone defs
    178 // of this class. Instances of subclass ProcResource will be automatically
    179 // attached to a processor, so SchedModel is not needed.
    180 class ProcResourceUnits<ProcResourceKind kind, int num> {
    181   ProcResourceKind Kind = kind;
    182   int NumUnits = num;
    183   ProcResourceKind Super = ?;
    184   int BufferSize = -1;
    185   SchedMachineModel SchedModel = ?;
    186 }
    187 
    188 // EponymousProcResourceKind helps implement ProcResourceUnits by
    189 // allowing a ProcResourceUnits definition to reference itself. It
    190 // should not be referenced anywhere else.
    191 def EponymousProcResourceKind : ProcResourceKind;
    192 
    193 // Subtargets typically define processor resource kind and number of
    194 // units in one place.
    195 class ProcResource<int num> : ProcResourceKind,
    196   ProcResourceUnits<EponymousProcResourceKind, num>;
    197 
    198 class ProcResGroup<list<ProcResource> resources> : ProcResourceKind {
    199   list<ProcResource> Resources = resources;
    200   SchedMachineModel SchedModel = ?;
    201   int BufferSize = -1;
    202 }
    203 
    204 // A target architecture may define SchedReadWrite types and associate
    205 // them with instruction operands.
    206 class SchedReadWrite;
    207 
    208 // List the per-operand types that map to the machine model of an
    209 // instruction. One SchedWrite type must be listed for each explicit
    210 // def operand in order. Additional SchedWrite types may optionally be
    211 // listed for implicit def operands.  SchedRead types may optionally
    212 // be listed for use operands in order. The order of defs relative to
    213 // uses is insignificant. This way, the same SchedReadWrite list may
    214 // be used for multiple forms of an operation. For example, a
    215 // two-address instruction could have two tied operands or single
    216 // operand that both reads and writes a reg. In both cases we have a
    217 // single SchedWrite and single SchedRead in any order.
    218 class Sched<list<SchedReadWrite> schedrw> {
    219   list<SchedReadWrite> SchedRW = schedrw;
    220 }
    221 
    222 // Define a scheduler resource associated with a def operand.
    223 class SchedWrite : SchedReadWrite;
    224 def NoWrite : SchedWrite;
    225 
    226 // Define a scheduler resource associated with a use operand.
    227 class SchedRead  : SchedReadWrite;
    228 
    229 // Define a SchedWrite that is modeled as a sequence of other
    230 // SchedWrites with additive latency. This allows a single operand to
    231 // be mapped the resources composed from a set of previously defined
    232 // SchedWrites.
    233 //
    234 // If the final write in this sequence is a SchedWriteVariant marked
    235 // Variadic, then the list of prior writes are distributed across all
    236 // operands after resolving the predicate for the final write.
    237 //
    238 // SchedModel silences warnings but is ignored.
    239 class WriteSequence<list<SchedWrite> writes, int rep = 1> : SchedWrite {
    240   list<SchedWrite> Writes = writes;
    241   int Repeat = rep;
    242   SchedMachineModel SchedModel = ?;
    243 }
    244 
    245 // Define values common to WriteRes and SchedWriteRes.
    246 //
    247 // SchedModel ties these resources to a processor.
    248 class ProcWriteResources<list<ProcResourceKind> resources> {
    249   list<ProcResourceKind> ProcResources = resources;
    250   list<int> ResourceCycles = [];
    251   int Latency = 1;
    252   int NumMicroOps = 1;
    253   bit BeginGroup = 0;
    254   bit EndGroup = 0;
    255   // Allow a processor to mark some scheduling classes as unsupported
    256   // for stronger verification.
    257   bit Unsupported = 0;
    258   // Allow a processor to mark some scheduling classes as single-issue.
    259   // SingleIssue is an alias for Begin/End Group.
    260   bit SingleIssue = 0;
    261   SchedMachineModel SchedModel = ?;
    262 }
    263 
    264 // Define the resources and latency of a SchedWrite. This will be used
    265 // directly by targets that have no itinerary classes. In this case,
    266 // SchedWrite is defined by the target, while WriteResources is
    267 // defined by the subtarget, and maps the SchedWrite to processor
    268 // resources.
    269 //
    270 // If a target already has itinerary classes, SchedWriteResources can
    271 // be used instead to define subtarget specific SchedWrites and map
    272 // them to processor resources in one place. Then ItinRW can map
    273 // itinerary classes to the subtarget's SchedWrites.
    274 //
    275 // ProcResources indicates the set of resources consumed by the write.
    276 // Optionally, ResourceCycles indicates the number of cycles the
    277 // resource is consumed. Each ResourceCycles item is paired with the
    278 // ProcResource item at the same position in its list. Since
    279 // ResourceCycles are rarely specialized, the list may be
    280 // incomplete. By default, resources are consumed for a single cycle,
    281 // regardless of latency, which models a fully pipelined processing
    282 // unit. A value of 0 for ResourceCycles means that the resource must
    283 // be available but is not consumed, which is only relevant for
    284 // unbuffered resources.
    285 //
    286 // By default, each SchedWrite takes one micro-op, which is counted
    287 // against the processor's IssueWidth limit. If an instruction can
    288 // write multiple registers with a single micro-op, the subtarget
    289 // should define one of the writes to be zero micro-ops. If a
    290 // subtarget requires multiple micro-ops to write a single result, it
    291 // should either override the write's NumMicroOps to be greater than 1
    292 // or require additional writes. Extra writes can be required either
    293 // by defining a WriteSequence, or simply listing extra writes in the
    294 // instruction's list of writers beyond the number of "def"
    295 // operands. The scheduler assumes that all micro-ops must be
    296 // dispatched in the same cycle. These micro-ops may be required to
    297 // begin or end the current dispatch group.
    298 class WriteRes<SchedWrite write, list<ProcResourceKind> resources>
    299   : ProcWriteResources<resources> {
    300   SchedWrite WriteType = write;
    301 }
    302 
    303 // Directly name a set of WriteResources defining a new SchedWrite
    304 // type at the same time. This class is unaware of its SchedModel so
    305 // must be referenced by InstRW or ItinRW.
    306 class SchedWriteRes<list<ProcResourceKind> resources> : SchedWrite,
    307   ProcWriteResources<resources>;
    308 
    309 // Define values common to ReadAdvance and SchedReadAdvance.
    310 //
    311 // SchedModel ties these resources to a processor.
    312 class ProcReadAdvance<int cycles, list<SchedWrite> writes = []> {
    313   int Cycles = cycles;
    314   list<SchedWrite> ValidWrites = writes;
    315   // Allow a processor to mark some scheduling classes as unsupported
    316   // for stronger verification.
    317   bit Unsupported = 0;
    318   SchedMachineModel SchedModel = ?;
    319 }
    320 
    321 // A processor may define a ReadAdvance associated with a SchedRead
    322 // to reduce latency of a prior write by N cycles. A negative advance
    323 // effectively increases latency, which may be used for cross-domain
    324 // stalls.
    325 //
    326 // A ReadAdvance may be associated with a list of SchedWrites
    327 // to implement pipeline bypass. The Writes list may be empty to
    328 // indicate operands that are always read this number of Cycles later
    329 // than a normal register read, allowing the read's parent instruction
    330 // to issue earlier relative to the writer.
    331 class ReadAdvance<SchedRead read, int cycles, list<SchedWrite> writes = []>
    332   : ProcReadAdvance<cycles, writes> {
    333   SchedRead ReadType = read;
    334 }
    335 
    336 // Directly associate a new SchedRead type with a delay and optional
    337 // pipeline bypass. For use with InstRW or ItinRW.
    338 class SchedReadAdvance<int cycles, list<SchedWrite> writes = []> : SchedRead,
    339   ProcReadAdvance<cycles, writes>;
    340 
    341 // Define SchedRead defaults. Reads seldom need special treatment.
    342 def ReadDefault : SchedRead;
    343 def NoReadAdvance : SchedReadAdvance<0>;
    344 
    345 // Define shared code that will be in the same scope as all
    346 // SchedPredicates. Available variables are:
    347 // (const MachineInstr *MI, const TargetSchedModel *SchedModel)
    348 class PredicateProlog<code c> {
    349   code Code = c;
    350 }
    351 
    352 // Define a predicate to determine which SchedVariant applies to a
    353 // particular MachineInstr. The code snippet is used as an
    354 // if-statement's expression. Available variables are MI, SchedModel,
    355 // and anything defined in a PredicateProlog.
    356 //
    357 // SchedModel silences warnings but is ignored.
    358 class SchedPredicate<code pred> {
    359   SchedMachineModel SchedModel = ?;
    360   code Predicate = pred;
    361 }
    362 def NoSchedPred : SchedPredicate<[{true}]>;
    363 
    364 // Associate a predicate with a list of SchedReadWrites. By default,
    365 // the selected SchedReadWrites are still associated with a single
    366 // operand and assumed to execute sequentially with additive
    367 // latency. However, if the parent SchedWriteVariant or
    368 // SchedReadVariant is marked "Variadic", then each Selected
    369 // SchedReadWrite is mapped in place to the instruction's variadic
    370 // operands. In this case, latency is not additive. If the current Variant
    371 // is already part of a Sequence, then that entire chain leading up to
    372 // the Variant is distributed over the variadic operands.
    373 class SchedVar<SchedPredicate pred, list<SchedReadWrite> selected> {
    374   SchedPredicate Predicate = pred;
    375   list<SchedReadWrite> Selected = selected;
    376 }
    377 
    378 // SchedModel silences warnings but is ignored.
    379 class SchedVariant<list<SchedVar> variants> {
    380   list<SchedVar> Variants = variants;
    381   bit Variadic = 0;
    382   SchedMachineModel SchedModel = ?;
    383 }
    384 
    385 // A SchedWriteVariant is a single SchedWrite type that maps to a list
    386 // of SchedWrite types under the conditions defined by its predicates.
    387 //
    388 // A Variadic write is expanded to cover multiple "def" operands. The
    389 // SchedVariant's Expansion list is then interpreted as one write
    390 // per-operand instead of the usual sequential writes feeding a single
    391 // operand.
    392 class SchedWriteVariant<list<SchedVar> variants> : SchedWrite,
    393   SchedVariant<variants> {
    394 }
    395 
    396 // A SchedReadVariant is a single SchedRead type that maps to a list
    397 // of SchedRead types under the conditions defined by its predicates.
    398 //
    399 // A Variadic write is expanded to cover multiple "readsReg" operands as
    400 // explained above.
    401 class SchedReadVariant<list<SchedVar> variants> : SchedRead,
    402   SchedVariant<variants> {
    403 }
    404 
    405 // Map a set of opcodes to a list of SchedReadWrite types. This allows
    406 // the subtarget to easily override specific operations.
    407 //
    408 // SchedModel ties this opcode mapping to a processor.
    409 class InstRW<list<SchedReadWrite> rw, dag instrlist> {
    410   list<SchedReadWrite> OperandReadWrites = rw;
    411   dag Instrs = instrlist;
    412   SchedMachineModel SchedModel = ?;
    413   // Allow a subtarget to mark some instructions as unsupported.
    414   bit Unsupported = 0;
    415 }
    416 
    417 // Map a set of itinerary classes to SchedReadWrite resources. This is
    418 // used to bootstrap a target (e.g. ARM) when itineraries already
    419 // exist and changing InstrInfo is undesirable.
    420 //
    421 // SchedModel ties this ItineraryClass mapping to a processor.
    422 class ItinRW<list<SchedReadWrite> rw, list<InstrItinClass> iic> {
    423   list<InstrItinClass> MatchedItinClasses = iic;
    424   list<SchedReadWrite> OperandReadWrites = rw;
    425   SchedMachineModel SchedModel = ?;
    426 }
    427 
    428 // Alias a target-defined SchedReadWrite to a processor specific
    429 // SchedReadWrite. This allows a subtarget to easily map a
    430 // SchedReadWrite type onto a WriteSequence, SchedWriteVariant, or
    431 // SchedReadVariant.
    432 //
    433 // SchedModel will usually be provided by surrounding let statement
    434 // and ties this SchedAlias mapping to a processor.
    435 class SchedAlias<SchedReadWrite match, SchedReadWrite alias> {
    436   SchedReadWrite MatchRW = match;
    437   SchedReadWrite AliasRW = alias;
    438   SchedMachineModel SchedModel = ?;
    439 }
    440