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// 120class 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. 129def NoItineraries : ProcessorItineraries<[], [], []>; 130 131