← Back to branch summary

~pali/+junk/llvm-toolchain-3.7

« back to all changes in this revision

Viewing changes to include/llvm/Target/TargetSchedule.td

  • Committer: Package Import Robot
  • Author(s): Sylvestre Ledru
  • Date: 2015-07-15 17:51:08 UTC
  • Revision ID: package-import@ubuntu.com-20150715175108-l8mynwovkx4zx697
Tags: upstream-3.7~+rc2
Import upstream version 3.7~+rc2

Show diffs side-by-side

added added

removed removed

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