]> CyberLeo.Net >> Repos - FreeBSD/releng/10.2.git/blob - contrib/llvm/include/llvm/Target/TargetSchedule.td
- Copy stable/10@285827 to releng/10.2 in preparation for 10.2-RC1
[FreeBSD/releng/10.2.git] / contrib / llvm / include / llvm / Target / TargetSchedule.td
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 itineraties 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 // DAG operator that interprets the DAG args as Instruction defs.
59 def instrs;
60
61 // DAG operator that interprets each DAG arg as a regex pattern for
62 // matching Instruction opcode names.
63 // The regex must match the beginning of the opcode (as in Python re.match).
64 // To avoid matching prefixes, append '$' to the pattern.
65 def instregex;
66
67 // Define the SchedMachineModel and provide basic properties for
68 // coarse grained instruction cost model. Default values for the
69 // properties are defined in MCSchedModel. A value of "-1" in the
70 // target description's SchedMachineModel indicates that the property
71 // is not overriden by the target.
72 //
73 // Target hooks allow subtargets to associate LoadLatency and
74 // HighLatency with groups of opcodes.
75 //
76 // See MCSchedule.h for detailed comments.
77 class SchedMachineModel {
78   int IssueWidth = -1; // Max micro-ops that may be scheduled per cycle.
79   int MinLatency = -1; // Determines which instructions are allowed in a group.
80                        // (-1) inorder (0) ooo, (1): inorder +var latencies.
81   int MicroOpBufferSize = -1; // Max micro-ops that can be buffered.
82   int LoadLatency = -1; // Cycles for loads to access the cache.
83   int HighLatency = -1; // Approximation of cycles for "high latency" ops.
84   int MispredictPenalty = -1; // Extra cycles for a mispredicted branch.
85
86   // Per-cycle resources tables.
87   ProcessorItineraries Itineraries = NoItineraries;
88
89   // Subtargets that define a model for only a subset of instructions
90   // that have a scheduling class (itinerary class or SchedRW list)
91   // and may actually be generated for that subtarget must clear this
92   // bit. Otherwise, the scheduler considers an unmodelled opcode to
93   // be an error. This should only be set during initial bringup,
94   // or there will be no way to catch simple errors in the model
95   // resulting from changes to the instruction definitions.
96   bit CompleteModel = 1;
97
98   bit NoModel = 0; // Special tag to indicate missing machine model.
99 }
100
101 def NoSchedModel : SchedMachineModel {
102   let NoModel = 1;
103 }
104
105 // Define a kind of processor resource that may be common across
106 // similar subtargets.
107 class ProcResourceKind;
108
109 // Define a number of interchangeable processor resources. NumUnits
110 // determines the throughput of instructions that require the resource.
111 //
112 // An optional Super resource may be given to model these resources as
113 // a subset of the more general super resources. Using one of these
114 // resources implies using one of the super resoruces.
115 //
116 // ProcResourceUnits normally model a few buffered resources within an
117 // out-of-order engine that the compiler attempts to conserve.
118 // Buffered resources may be held for multiple clock cycles, but the
119 // scheduler does not pin them to a particular clock cycle relative to
120 // instruction dispatch. Setting BufferSize=0 changes this to an
121 // in-order resource. In this case, the scheduler counts down from the
122 // cycle that the instruction issues in-order, forcing an interlock
123 // with subsequent instructions that require the same resource until
124 // the number of ResourceCyles specified in WriteRes expire.
125 //
126 // SchedModel ties these units to a processor for any stand-alone defs
127 // of this class. Instances of subclass ProcResource will be automatically
128 // attached to a processor, so SchedModel is not needed.
129 class ProcResourceUnits<ProcResourceKind kind, int num> {
130   ProcResourceKind Kind = kind;
131   int NumUnits = num;
132   ProcResourceKind Super = ?;
133   int BufferSize = -1;
134   SchedMachineModel SchedModel = ?;
135 }
136
137 // EponymousProcResourceKind helps implement ProcResourceUnits by
138 // allowing a ProcResourceUnits definition to reference itself. It
139 // should not be referenced anywhere else.
140 def EponymousProcResourceKind : ProcResourceKind;
141
142 // Subtargets typically define processor resource kind and number of
143 // units in one place.
144 class ProcResource<int num> : ProcResourceKind,
145   ProcResourceUnits<EponymousProcResourceKind, num>;
146
147 class ProcResGroup<list<ProcResource> resources> : ProcResourceKind {
148   list<ProcResource> Resources = resources;
149   SchedMachineModel SchedModel = ?;
150   int BufferSize = -1;
151 }
152
153 // A target architecture may define SchedReadWrite types and associate
154 // them with instruction operands.
155 class SchedReadWrite;
156
157 // List the per-operand types that map to the machine model of an
158 // instruction. One SchedWrite type must be listed for each explicit
159 // def operand in order. Additional SchedWrite types may optionally be
160 // listed for implicit def operands.  SchedRead types may optionally
161 // be listed for use operands in order. The order of defs relative to
162 // uses is insignificant. This way, the same SchedReadWrite list may
163 // be used for multiple forms of an operation. For example, a
164 // two-address instruction could have two tied operands or single
165 // operand that both reads and writes a reg. In both cases we have a
166 // single SchedWrite and single SchedRead in any order.
167 class Sched<list<SchedReadWrite> schedrw> {
168   list<SchedReadWrite> SchedRW = schedrw;
169 }
170
171 // Define a scheduler resource associated with a def operand.
172 class SchedWrite : SchedReadWrite;
173 def NoWrite : SchedWrite;
174
175 // Define a scheduler resource associated with a use operand.
176 class SchedRead  : SchedReadWrite;
177
178 // Define a SchedWrite that is modeled as a sequence of other
179 // SchedWrites with additive latency. This allows a single operand to
180 // be mapped the resources composed from a set of previously defined
181 // SchedWrites.
182 //
183 // If the final write in this sequence is a SchedWriteVariant marked
184 // Variadic, then the list of prior writes are distributed across all
185 // operands after resolving the predicate for the final write.
186 //
187 // SchedModel silences warnings but is ignored.
188 class WriteSequence<list<SchedWrite> writes, int rep = 1> : SchedWrite {
189   list<SchedWrite> Writes = writes;
190   int Repeat = rep;
191   SchedMachineModel SchedModel = ?;
192 }
193
194 // Define values common to WriteRes and SchedWriteRes.
195 //
196 // SchedModel ties these resources to a processor.
197 class ProcWriteResources<list<ProcResourceKind> resources> {
198   list<ProcResourceKind> ProcResources = resources;
199   list<int> ResourceCycles = [];
200   int Latency = 1;
201   int NumMicroOps = 1;
202   bit BeginGroup = 0;
203   bit EndGroup = 0;
204   // Allow a processor to mark some scheduling classes as unsupported
205   // for stronger verification.
206   bit Unsupported = 0;
207   SchedMachineModel SchedModel = ?;
208 }
209
210 // Define the resources and latency of a SchedWrite. This will be used
211 // directly by targets that have no itinerary classes. In this case,
212 // SchedWrite is defined by the target, while WriteResources is
213 // defined by the subtarget, and maps the SchedWrite to processor
214 // resources.
215 //
216 // If a target already has itinerary classes, SchedWriteResources can
217 // be used instead to define subtarget specific SchedWrites and map
218 // them to processor resources in one place. Then ItinRW can map
219 // itinerary classes to the subtarget's SchedWrites.
220 //
221 // ProcResources indicates the set of resources consumed by the write.
222 // Optionally, ResourceCycles indicates the number of cycles the
223 // resource is consumed. Each ResourceCycles item is paired with the
224 // ProcResource item at the same position in its list. Since
225 // ResourceCycles are rarely specialized, the list may be
226 // incomplete. By default, resources are consumed for a single cycle,
227 // regardless of latency, which models a fully pipelined processing
228 // unit. A value of 0 for ResourceCycles means that the resource must
229 // be available but is not consumed, which is only relevant for
230 // unbuffered resources.
231 //
232 // By default, each SchedWrite takes one micro-op, which is counted
233 // against the processor's IssueWidth limit. If an instruction can
234 // write multiple registers with a single micro-op, the subtarget
235 // should define one of the writes to be zero micro-ops. If a
236 // subtarget requires multiple micro-ops to write a single result, it
237 // should either override the write's NumMicroOps to be greater than 1
238 // or require additional writes. Extra writes can be required either
239 // by defining a WriteSequence, or simply listing extra writes in the
240 // instruction's list of writers beyond the number of "def"
241 // operands. The scheduler assumes that all micro-ops must be
242 // dispatched in the same cycle. These micro-ops may be required to
243 // begin or end the current dispatch group.
244 class WriteRes<SchedWrite write, list<ProcResourceKind> resources>
245   : ProcWriteResources<resources> {
246   SchedWrite WriteType = write;
247 }
248
249 // Directly name a set of WriteResources defining a new SchedWrite
250 // type at the same time. This class is unaware of its SchedModel so
251 // must be referenced by InstRW or ItinRW.
252 class SchedWriteRes<list<ProcResourceKind> resources> : SchedWrite,
253   ProcWriteResources<resources>;
254
255 // Define values common to ReadAdvance and SchedReadAdvance.
256 //
257 // SchedModel ties these resources to a processor.
258 class ProcReadAdvance<int cycles, list<SchedWrite> writes = []> {
259   int Cycles = cycles;
260   list<SchedWrite> ValidWrites = writes;
261   // Allow a processor to mark some scheduling classes as unsupported
262   // for stronger verification.
263   bit Unsupported = 0;
264   SchedMachineModel SchedModel = ?;
265 }
266
267 // A processor may define a ReadAdvance associated with a SchedRead
268 // to reduce latency of a prior write by N cycles. A negative advance
269 // effectively increases latency, which may be used for cross-domain
270 // stalls.
271 //
272 // A ReadAdvance may be associated with a list of SchedWrites
273 // to implement pipeline bypass. The Writes list may be empty to
274 // indicate operands that are always read this number of Cycles later
275 // than a normal register read, allowing the read's parent instruction
276 // to issue earlier relative to the writer.
277 class ReadAdvance<SchedRead read, int cycles, list<SchedWrite> writes = []>
278   : ProcReadAdvance<cycles, writes> {
279   SchedRead ReadType = read;
280 }
281
282 // Directly associate a new SchedRead type with a delay and optional
283 // pipeline bypess. For use with InstRW or ItinRW.
284 class SchedReadAdvance<int cycles, list<SchedWrite> writes = []> : SchedRead,
285   ProcReadAdvance<cycles, writes>;
286
287 // Define SchedRead defaults. Reads seldom need special treatment.
288 def ReadDefault : SchedRead;
289 def NoReadAdvance : SchedReadAdvance<0>;
290
291 // Define shared code that will be in the same scope as all
292 // SchedPredicates. Available variables are:
293 // (const MachineInstr *MI, const TargetSchedModel *SchedModel)
294 class PredicateProlog<code c> {
295   code Code = c;
296 }
297
298 // Define a predicate to determine which SchedVariant applies to a
299 // particular MachineInstr. The code snippet is used as an
300 // if-statement's expression. Available variables are MI, SchedModel,
301 // and anything defined in a PredicateProlog.
302 //
303 // SchedModel silences warnings but is ignored.
304 class SchedPredicate<code pred> {
305   SchedMachineModel SchedModel = ?;
306   code Predicate = pred;
307 }
308 def NoSchedPred : SchedPredicate<[{true}]>;
309
310 // Associate a predicate with a list of SchedReadWrites. By default,
311 // the selected SchedReadWrites are still associated with a single
312 // operand and assumed to execute sequentially with additive
313 // latency. However, if the parent SchedWriteVariant or
314 // SchedReadVariant is marked "Variadic", then each Selected
315 // SchedReadWrite is mapped in place to the instruction's variadic
316 // operands. In this case, latency is not additive. If the current Variant
317 // is already part of a Sequence, then that entire chain leading up to
318 // the Variant is distributed over the variadic operands.
319 class SchedVar<SchedPredicate pred, list<SchedReadWrite> selected> {
320   SchedPredicate Predicate = pred;
321   list<SchedReadWrite> Selected = selected;
322 }
323
324 // SchedModel silences warnings but is ignored.
325 class SchedVariant<list<SchedVar> variants> {
326   list<SchedVar> Variants = variants;
327   bit Variadic = 0;
328   SchedMachineModel SchedModel = ?;
329 }
330
331 // A SchedWriteVariant is a single SchedWrite type that maps to a list
332 // of SchedWrite types under the conditions defined by its predicates.
333 //
334 // A Variadic write is expanded to cover multiple "def" operands. The
335 // SchedVariant's Expansion list is then interpreted as one write
336 // per-operand instead of the usual sequential writes feeding a single
337 // operand.
338 class SchedWriteVariant<list<SchedVar> variants> : SchedWrite,
339   SchedVariant<variants> {
340 }
341
342 // A SchedReadVariant is a single SchedRead type that maps to a list
343 // of SchedRead types under the conditions defined by its predicates.
344 //
345 // A Variadic write is expanded to cover multiple "readsReg" operands as
346 // explained above.
347 class SchedReadVariant<list<SchedVar> variants> : SchedRead,
348   SchedVariant<variants> {
349 }
350
351 // Map a set of opcodes to a list of SchedReadWrite types. This allows
352 // the subtarget to easily override specific operations.
353 //
354 // SchedModel ties this opcode mapping to a processor.
355 class InstRW<list<SchedReadWrite> rw, dag instrlist> {
356   list<SchedReadWrite> OperandReadWrites = rw;
357   dag Instrs = instrlist;
358   SchedMachineModel SchedModel = ?;
359 }
360
361 // Map a set of itinerary classes to SchedReadWrite resources. This is
362 // used to bootstrap a target (e.g. ARM) when itineraries already
363 // exist and changing InstrInfo is undesirable.
364 //
365 // SchedModel ties this ItineraryClass mapping to a processor.
366 class ItinRW<list<SchedReadWrite> rw, list<InstrItinClass> iic> {
367   list<InstrItinClass> MatchedItinClasses = iic;
368   list<SchedReadWrite> OperandReadWrites = rw;
369   SchedMachineModel SchedModel = ?;
370 }
371
372 // Alias a target-defined SchedReadWrite to a processor specific
373 // SchedReadWrite. This allows a subtarget to easily map a
374 // SchedReadWrite type onto a WriteSequence, SchedWriteVariant, or
375 // SchedReadVariant.
376 //
377 // SchedModel will usually be provided by surrounding let statement
378 // and ties this SchedAlias mapping to a processor.
379 class SchedAlias<SchedReadWrite match, SchedReadWrite alias> {
380   SchedReadWrite MatchRW = match;
381   SchedReadWrite AliasRW = alias;
382   SchedMachineModel SchedModel = ?;
383 }