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