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 class ProcessorItineraries<list<FuncUnit> fu, list<Bypass> bp, 121 list<InstrItinData> iid> { 122 list<FuncUnit> FU = fu; 123 list<Bypass> BP = bp; 124 list<InstrItinData> IID = iid; 125 } 126 127 // NoItineraries - A marker that can be used by processors without schedule 128 // info. 129 def NoItineraries : ProcessorItineraries<[], [], []>; 130 131
