TargetSchedule.td revision d85934b3e5a96040e199e1b098705eb56cde584a
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// 23class 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. 29class Bypass; 30def NoBypass : Bypass; 31 32class ReservationKind<bits<1> val> { 33 int Value = val; 34} 35 36def Required : ReservationKind<0>; 37def 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 54class 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// 81class InstrItinClass<int ops = 1> { 82 int NumMicroOps = ops; 83} 84def 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. 107class 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. 122class 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. 138def 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. 142class 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} 152