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 //===----------------------------------------------------------------------===//
  14
  15 //===----------------------------------------------------------------------===//
  16 // Processor functional unit - These values represent the function units
  17 // available across all chip sets for the target.  Eg., IntUnit, FPUnit, ...
  18 // These may be independent values for each chip set or may be shared across
  19 // all chip sets of the target.  Each functional unit is treated as a resource
  20 // during scheduling and has an affect instruction order based on availability
  21 // during a time interval.
  22 //
  23 class FuncUnit;
  24
  25 //===----------------------------------------------------------------------===//
  26 // Pipeline bypass / forwarding - These values specifies the symbolic names of
  27 // pipeline bypasses which can be used to forward results of instructions
  28 // that are forwarded to uses.
  29 class Bypass;
  30 def NoBypass : Bypass;
  31
  32 class ReservationKind<bits<1> val> {
  33   int Value = val;
  34 }
  35
  36 def Required : ReservationKind<0>;
  37 def Reserved : ReservationKind<1>;
  38
  39 //===----------------------------------------------------------------------===//
  40 // Instruction stage - These values represent a non-pipelined step in
  41 // the execution of an instruction.  Cycles represents the number of
  42 // discrete time slots needed to complete the stage.  Units represent
  43 // the choice of functional units that can be used to complete the
  44 // stage.  Eg. IntUnit1, IntUnit2. NextCycles indicates how many
  45 // cycles should elapse from the start of this stage to the start of
  46 // the next stage in the itinerary.  For example:
  47 //
  48 // A stage is specified in one of two ways:
  49 //
  50 //   InstrStage<1, [FU_x, FU_y]>     - TimeInc defaults to Cycles
  51 //   InstrStage<1, [FU_x, FU_y], 0>  - TimeInc explicit
  52 //
  53
  54 class InstrStage<int cycles, list<FuncUnit> units,
  55                  int timeinc = -1,
  56                  ReservationKind kind = Required> {
  57   int Cycles          = cycles;       // length of stage in machine cycles
  58   list<FuncUnit> Units = units;       // choice of functional units
  59   int TimeInc         = timeinc;      // cycles till start of next stage
  60   int Kind            = kind.Value;   // kind of FU reservation
  61 }
  62
  63 //===----------------------------------------------------------------------===//
  64 // Instruction itinerary - An itinerary represents a sequential series of steps
  65 // required to complete an instruction.  Itineraries are represented as lists of
  66 // instruction stages.
  67 //
  68
  69 //===----------------------------------------------------------------------===//
  70 // Instruction itinerary classes - These values represent 'named' instruction
  71 // itinerary.  Using named itineraries simplifies managing groups of
  72 // instructions across chip sets.  An instruction uses the same itinerary class
  73 // across all chip sets.  Thus a new chip set can be added without modifying
  74 // instruction information.
  75 //
  76 // NumMicroOps represents the number of micro-operations that each instruction
  77 // in the class are decoded to. If the number is zero, then it means the
  78 // instruction can decode into variable number of micro-ops and it must be
  79 // determined dynamically.
  80 //
  81 class InstrItinClass<int ops = 1> {
  82   int NumMicroOps = ops;
  83 }
  84 def NoItinerary : InstrItinClass;
  85
  86 //===----------------------------------------------------------------------===//
  87 // Instruction itinerary data - These values provide a runtime map of an
  88 // instruction itinerary class (name) to its itinerary data.
  89 //
  90 // OperandCycles are optional "cycle counts". They specify the cycle after
  91 // instruction issue the values which correspond to specific operand indices
  92 // are defined or read. Bypasses are optional "pipeline forwarding pathes", if
  93 // a def by an instruction is available on a specific bypass and the use can
  94 // read from the same bypass, then the operand use latency is reduced by one.
  95 //
  96 //  InstrItinData<IIC_iLoad_i , [InstrStage<1, [A9_Pipe1]>,
  97 //                               InstrStage<1, [A9_AGU]>],
  98 //                              [3, 1], [A9_LdBypass]>,
  99 //  InstrItinData<IIC_iMVNr   , [InstrStage<1, [A9_Pipe0, A9_Pipe1]>],
 100 //                              [1, 1], [NoBypass, A9_LdBypass]>,
 101 //
 102 // In this example, the instruction of IIC_iLoadi reads its input on cycle 1
 103 // (after issue) and the result of the load is available on cycle 3. The result
 104 // is available via forwarding path A9_LdBypass. If it's used by the first
 105 // source operand of instructions of IIC_iMVNr class, then the operand latency
 106 // is reduced by 1.
 107 class InstrItinData<InstrItinClass Class, list<InstrStage> stages,
 108                     list<int> operandcycles = [],
 109                     list<Bypass> bypasses = []> {
 110   InstrItinClass TheClass = Class;
 111   list<InstrStage> Stages = stages;
 112   list<int> OperandCycles = operandcycles;
 113   list<Bypass> Bypasses = bypasses;
 114 }
 115
 116 //===----------------------------------------------------------------------===//
 117 // Processor itineraries - These values represent the set of all itinerary
 118 // classes for a given chip set.
 119 //
 120 // Set property values to -1 to use the default.
 121 // See InstrItineraryProps for comments and defaults.
 122 class ProcessorItineraries<list<FuncUnit> fu, list<Bypass> bp,
 123                            list<InstrItinData> iid> {
 124   int IssueWidth = -1; // Max instructions that may be scheduled per cycle.
 125   int MinLatency = -1; // Determines which instrucions are allowed in a group.
 126                        // (-1) inorder (0) ooo, (1): inorder +var latencies.
 127   int LoadLatency = -1; // Cycles for loads to access the cache.
 128   int HighLatency = -1; // Approximation of cycles for "high latency" ops.
 129
 130   list<FuncUnit> FU = fu;
 131   list<Bypass> BP = bp;
 132   list<InstrItinData> IID = iid;
 133 }
 134
 135 // NoItineraries - A marker that can be used by processors without schedule
 136 // info. Subtargets using NoItineraries can bypass the scheduler's
 137 // expensive HazardRecognizer because no reservation table is needed.
 138 def NoItineraries : ProcessorItineraries<[], [], []>;
 139
 140 // Processor itineraries with non-unit issue width. This allows issue
 141 // width to be explicity specified at the beginning of the itinerary.
 142 class MultiIssueItineraries<int issuewidth, int minlatency,
 143                             int loadlatency, int highlatency,
 144                             list<FuncUnit> fu, list<Bypass> bp,
 145                             list<InstrItinData> iid>
 146   : ProcessorItineraries<fu, bp, iid> {
 147   let IssueWidth = issuewidth;
 148   let MinLatency = minlatency;
 149   let LoadLatency = loadlatency;
 150   let HighLatency = highlatency;
 151 }