mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-24 11:42:57 +01:00
b9c8074dcd
subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
137 lines
6.2 KiB
TableGen
137 lines
6.2 KiB
TableGen
//===- TargetItinerary.td - Target Itinierary Description --*- tablegen -*-===//
|
|
//
|
|
// The LLVM Compiler Infrastructure
|
|
//
|
|
// This file is distributed under the University of Illinois Open Source
|
|
// License. See LICENSE.TXT for details.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
//
|
|
// This file defines the target-independent scheduling interfaces
|
|
// which should be implemented by each target that uses instruction
|
|
// itineraries for scheduling. Itineraries are details reservation
|
|
// tables for each instruction class. They are most appropriate for
|
|
// in-order machine with complicated scheduling or bundling constraints.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Processor functional unit - These values represent the function units
|
|
// available across all chip sets for the target. Eg., IntUnit, FPUnit, ...
|
|
// These may be independent values for each chip set or may be shared across
|
|
// all chip sets of the target. Each functional unit is treated as a resource
|
|
// during scheduling and has an affect instruction order based on availability
|
|
// during a time interval.
|
|
//
|
|
class FuncUnit;
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Pipeline bypass / forwarding - These values specifies the symbolic names of
|
|
// pipeline bypasses which can be used to forward results of instructions
|
|
// that are forwarded to uses.
|
|
class Bypass;
|
|
def NoBypass : Bypass;
|
|
|
|
class ReservationKind<bits<1> val> {
|
|
int Value = val;
|
|
}
|
|
|
|
def Required : ReservationKind<0>;
|
|
def Reserved : ReservationKind<1>;
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Instruction stage - These values represent a non-pipelined step in
|
|
// the execution of an instruction. Cycles represents the number of
|
|
// discrete time slots needed to complete the stage. Units represent
|
|
// the choice of functional units that can be used to complete the
|
|
// stage. Eg. IntUnit1, IntUnit2. NextCycles indicates how many
|
|
// cycles should elapse from the start of this stage to the start of
|
|
// the next stage in the itinerary. For example:
|
|
//
|
|
// A stage is specified in one of two ways:
|
|
//
|
|
// InstrStage<1, [FU_x, FU_y]> - TimeInc defaults to Cycles
|
|
// InstrStage<1, [FU_x, FU_y], 0> - TimeInc explicit
|
|
//
|
|
|
|
class InstrStage<int cycles, list<FuncUnit> units,
|
|
int timeinc = -1,
|
|
ReservationKind kind = Required> {
|
|
int Cycles = cycles; // length of stage in machine cycles
|
|
list<FuncUnit> Units = units; // choice of functional units
|
|
int TimeInc = timeinc; // cycles till start of next stage
|
|
int Kind = kind.Value; // kind of FU reservation
|
|
}
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Instruction itinerary - An itinerary represents a sequential series of steps
|
|
// required to complete an instruction. Itineraries are represented as lists of
|
|
// instruction stages.
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Instruction itinerary classes - These values represent 'named' instruction
|
|
// itinerary. Using named itineraries simplifies managing groups of
|
|
// instructions across chip sets. An instruction uses the same itinerary class
|
|
// across all chip sets. Thus a new chip set can be added without modifying
|
|
// instruction information.
|
|
//
|
|
class InstrItinClass;
|
|
def NoItinerary : InstrItinClass;
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Instruction itinerary data - These values provide a runtime map of an
|
|
// instruction itinerary class (name) to its itinerary data.
|
|
//
|
|
// NumMicroOps represents the number of micro-operations that each instruction
|
|
// in the class are decoded to. If the number is zero, then it means the
|
|
// instruction can decode into variable number of micro-ops and it must be
|
|
// determined dynamically. This directly relates to the itineraries
|
|
// global IssueWidth property, which constrains the number of microops
|
|
// that can issue per cycle.
|
|
//
|
|
// OperandCycles are optional "cycle counts". They specify the cycle after
|
|
// instruction issue the values which correspond to specific operand indices
|
|
// are defined or read. Bypasses are optional "pipeline forwarding pathes", if
|
|
// a def by an instruction is available on a specific bypass and the use can
|
|
// read from the same bypass, then the operand use latency is reduced by one.
|
|
//
|
|
// InstrItinData<IIC_iLoad_i , [InstrStage<1, [A9_Pipe1]>,
|
|
// InstrStage<1, [A9_AGU]>],
|
|
// [3, 1], [A9_LdBypass]>,
|
|
// InstrItinData<IIC_iMVNr , [InstrStage<1, [A9_Pipe0, A9_Pipe1]>],
|
|
// [1, 1], [NoBypass, A9_LdBypass]>,
|
|
//
|
|
// In this example, the instruction of IIC_iLoadi reads its input on cycle 1
|
|
// (after issue) and the result of the load is available on cycle 3. The result
|
|
// is available via forwarding path A9_LdBypass. If it's used by the first
|
|
// source operand of instructions of IIC_iMVNr class, then the operand latency
|
|
// is reduced by 1.
|
|
class InstrItinData<InstrItinClass Class, list<InstrStage> stages,
|
|
list<int> operandcycles = [],
|
|
list<Bypass> bypasses = [], int uops = 1> {
|
|
InstrItinClass TheClass = Class;
|
|
int NumMicroOps = uops;
|
|
list<InstrStage> Stages = stages;
|
|
list<int> OperandCycles = operandcycles;
|
|
list<Bypass> Bypasses = bypasses;
|
|
}
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
// Processor itineraries - These values represent the set of all itinerary
|
|
// classes for a given chip set.
|
|
//
|
|
// Set property values to -1 to use the default.
|
|
// See InstrItineraryProps for comments and defaults.
|
|
class ProcessorItineraries<list<FuncUnit> fu, list<Bypass> bp,
|
|
list<InstrItinData> iid> {
|
|
list<FuncUnit> FU = fu;
|
|
list<Bypass> BP = bp;
|
|
list<InstrItinData> IID = iid;
|
|
}
|
|
|
|
// NoItineraries - A marker that can be used by processors without schedule
|
|
// info. Subtargets using NoItineraries can bypass the scheduler's
|
|
// expensive HazardRecognizer because no reservation table is needed.
|
|
def NoItineraries : ProcessorItineraries<[], [], []>;
|