mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-22 04:22:57 +02:00
This patch refactors the logic that expands predicates of a variant scheduling class. The idea is to improve the readability of the auto-generated code by removing redundant parentheses around predicate expressions, and by removing redundant if(true) statements. This patch replaces the definition of NoSchedPred in TargetSchedule.td with an instance of MCSchedPredicate. The new definition is sematically equivalent to the previous one. The main difference is that now SubtargetEmitter knows that it represents predicate "true". Before this patch, we always generated an if (true) for the default transition of a variant scheduling class. Example (taken from AArch64GenSubtargetInfo.inc) : ``` if (SchedModel->getProcessorID() == 3) { // CycloneModel if ((TII->isScaledAddr(*MI))) return 927; // (WriteIS_WriteLD)_ReadBaseRS if ((true)) return 928; // WriteLD_ReadDefault } ``` Extra parentheses were also generated around the predicate expressions. With this patch, we get the following auto-generated checks: ``` if (SchedModel->getProcessorID() == 3) { // CycloneModel if (TII->isScaledAddr(*MI)) return 927; // (WriteIS_WriteLD)_ReadBaseRS return 928; // WriteLD_ReadDefault } ``` The new auto-generated code behaves exactly the same as before. So, technically this is a non functional change. Differential revision: https://reviews.llvm.org/D50566 llvm-svn: 339552
553 lines
24 KiB
TableGen
553 lines
24 KiB
TableGen
//===- TargetSchedule.td - Target Independent Scheduling ---*- 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 which is using TableGen based scheduling.
|
|
//
|
|
// The SchedMachineModel is defined by subtargets for three categories of data:
|
|
// 1. Basic properties for coarse grained instruction cost model.
|
|
// 2. Scheduler Read/Write resources for simple per-opcode cost model.
|
|
// 3. Instruction itineraries for detailed reservation tables.
|
|
//
|
|
// (1) Basic properties are defined by the SchedMachineModel
|
|
// class. Target hooks allow subtargets to associate opcodes with
|
|
// those properties.
|
|
//
|
|
// (2) A per-operand machine model can be implemented in any
|
|
// combination of the following ways:
|
|
//
|
|
// A. Associate per-operand SchedReadWrite types with Instructions by
|
|
// modifying the Instruction definition to inherit from Sched. For
|
|
// each subtarget, define WriteRes and ReadAdvance to associate
|
|
// processor resources and latency with each SchedReadWrite type.
|
|
//
|
|
// B. In each instruction definition, name an ItineraryClass. For each
|
|
// subtarget, define ItinRW entries to map ItineraryClass to
|
|
// per-operand SchedReadWrite types. Unlike method A, these types may
|
|
// be subtarget specific and can be directly associated with resources
|
|
// by defining SchedWriteRes and SchedReadAdvance.
|
|
//
|
|
// C. In the subtarget, map SchedReadWrite types to specific
|
|
// opcodes. This overrides any SchedReadWrite types or
|
|
// ItineraryClasses defined by the Instruction. As in method B, the
|
|
// subtarget can directly associate resources with SchedReadWrite
|
|
// types by defining SchedWriteRes and SchedReadAdvance.
|
|
//
|
|
// D. In either the target or subtarget, define SchedWriteVariant or
|
|
// SchedReadVariant to map one SchedReadWrite type onto another
|
|
// sequence of SchedReadWrite types. This allows dynamic selection of
|
|
// an instruction's machine model via custom C++ code. It also allows
|
|
// a machine-independent SchedReadWrite type to map to a sequence of
|
|
// machine-dependent types.
|
|
//
|
|
// (3) A per-pipeline-stage machine model can be implemented by providing
|
|
// Itineraries in addition to mapping instructions to ItineraryClasses.
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Include legacy support for instruction itineraries.
|
|
include "llvm/Target/TargetItinerary.td"
|
|
|
|
class Instruction; // Forward def
|
|
|
|
class Predicate; // Forward def
|
|
|
|
// DAG operator that interprets the DAG args as Instruction defs.
|
|
def instrs;
|
|
|
|
// DAG operator that interprets each DAG arg as a regex pattern for
|
|
// matching Instruction opcode names.
|
|
// The regex must match the beginning of the opcode (as in Python re.match).
|
|
// To avoid matching prefixes, append '$' to the pattern.
|
|
def instregex;
|
|
|
|
// Define the SchedMachineModel and provide basic properties for
|
|
// coarse grained instruction cost model. Default values for the
|
|
// properties are defined in MCSchedModel. A value of "-1" in the
|
|
// target description's SchedMachineModel indicates that the property
|
|
// is not overriden by the target.
|
|
//
|
|
// Target hooks allow subtargets to associate LoadLatency and
|
|
// HighLatency with groups of opcodes.
|
|
//
|
|
// See MCSchedule.h for detailed comments.
|
|
class SchedMachineModel {
|
|
int IssueWidth = -1; // Max micro-ops that may be scheduled per cycle.
|
|
int MicroOpBufferSize = -1; // Max micro-ops that can be buffered.
|
|
int LoopMicroOpBufferSize = -1; // Max micro-ops that can be buffered for
|
|
// optimized loop dispatch/execution.
|
|
int LoadLatency = -1; // Cycles for loads to access the cache.
|
|
int HighLatency = -1; // Approximation of cycles for "high latency" ops.
|
|
int MispredictPenalty = -1; // Extra cycles for a mispredicted branch.
|
|
|
|
// Per-cycle resources tables.
|
|
ProcessorItineraries Itineraries = NoItineraries;
|
|
|
|
bit PostRAScheduler = 0; // Enable Post RegAlloc Scheduler pass.
|
|
|
|
// Subtargets that define a model for only a subset of instructions
|
|
// that have a scheduling class (itinerary class or SchedRW list)
|
|
// and may actually be generated for that subtarget must clear this
|
|
// bit. Otherwise, the scheduler considers an unmodelled opcode to
|
|
// be an error. This should only be set during initial bringup,
|
|
// or there will be no way to catch simple errors in the model
|
|
// resulting from changes to the instruction definitions.
|
|
bit CompleteModel = 1;
|
|
|
|
// Indicates that we should do full overlap checking for multiple InstrRWs
|
|
// definining the same instructions within the same SchedMachineModel.
|
|
// FIXME: Remove when all in tree targets are clean with the full check
|
|
// enabled.
|
|
bit FullInstRWOverlapCheck = 1;
|
|
|
|
// A processor may only implement part of published ISA, due to either new ISA
|
|
// extensions, (e.g. Pentium 4 doesn't have AVX) or implementation
|
|
// (ARM/MIPS/PowerPC/SPARC soft float cores).
|
|
//
|
|
// For a processor which doesn't support some feature(s), the schedule model
|
|
// can use:
|
|
//
|
|
// let<Predicate> UnsupportedFeatures = [HaveA,..,HaveY];
|
|
//
|
|
// to skip the checks for scheduling information when building LLVM for
|
|
// instructions which have any of the listed predicates in their Predicates
|
|
// field.
|
|
list<Predicate> UnsupportedFeatures = [];
|
|
|
|
bit NoModel = 0; // Special tag to indicate missing machine model.
|
|
}
|
|
|
|
def NoSchedModel : SchedMachineModel {
|
|
let NoModel = 1;
|
|
let CompleteModel = 0;
|
|
}
|
|
|
|
// Define a kind of processor resource that may be common across
|
|
// similar subtargets.
|
|
class ProcResourceKind;
|
|
|
|
// Define a number of interchangeable processor resources. NumUnits
|
|
// determines the throughput of instructions that require the resource.
|
|
//
|
|
// An optional Super resource may be given to model these resources as
|
|
// a subset of the more general super resources. Using one of these
|
|
// resources implies using one of the super resoruces.
|
|
//
|
|
// ProcResourceUnits normally model a few buffered resources within an
|
|
// out-of-order engine. Buffered resources may be held for multiple
|
|
// clock cycles, but the scheduler does not pin them to a particular
|
|
// clock cycle relative to instruction dispatch. Setting BufferSize=0
|
|
// changes this to an in-order issue/dispatch resource. In this case,
|
|
// the scheduler counts down from the cycle that the instruction
|
|
// issues in-order, forcing a stall whenever a subsequent instruction
|
|
// requires the same resource until the number of ResourceCycles
|
|
// specified in WriteRes expire. Setting BufferSize=1 changes this to
|
|
// an in-order latency resource. In this case, the scheduler models
|
|
// producer/consumer stalls between instructions that use the
|
|
// resource.
|
|
//
|
|
// Examples (all assume an out-of-order engine):
|
|
//
|
|
// Use BufferSize = -1 for "issue ports" fed by a unified reservation
|
|
// station. Here the size of the reservation station is modeled by
|
|
// MicroOpBufferSize, which should be the minimum size of either the
|
|
// register rename pool, unified reservation station, or reorder
|
|
// buffer.
|
|
//
|
|
// Use BufferSize = 0 for resources that force "dispatch/issue
|
|
// groups". (Different processors define dispath/issue
|
|
// differently. Here we refer to stage between decoding into micro-ops
|
|
// and moving them into a reservation station.) Normally NumMicroOps
|
|
// is sufficient to limit dispatch/issue groups. However, some
|
|
// processors can form groups of with only certain combinitions of
|
|
// instruction types. e.g. POWER7.
|
|
//
|
|
// Use BufferSize = 1 for in-order execution units. This is used for
|
|
// an in-order pipeline within an out-of-order core where scheduling
|
|
// dependent operations back-to-back is guaranteed to cause a
|
|
// bubble. e.g. Cortex-a9 floating-point.
|
|
//
|
|
// Use BufferSize > 1 for out-of-order executions units with a
|
|
// separate reservation station. This simply models the size of the
|
|
// reservation station.
|
|
//
|
|
// To model both dispatch/issue groups and in-order execution units,
|
|
// create two types of units, one with BufferSize=0 and one with
|
|
// BufferSize=1.
|
|
//
|
|
// SchedModel ties these units to a processor for any stand-alone defs
|
|
// of this class.
|
|
class ProcResourceUnits<ProcResourceKind kind, int num> {
|
|
ProcResourceKind Kind = kind;
|
|
int NumUnits = num;
|
|
ProcResourceKind Super = ?;
|
|
int BufferSize = -1;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// EponymousProcResourceKind helps implement ProcResourceUnits by
|
|
// allowing a ProcResourceUnits definition to reference itself. It
|
|
// should not be referenced anywhere else.
|
|
def EponymousProcResourceKind : ProcResourceKind;
|
|
|
|
// Subtargets typically define processor resource kind and number of
|
|
// units in one place.
|
|
class ProcResource<int num> : ProcResourceKind,
|
|
ProcResourceUnits<EponymousProcResourceKind, num>;
|
|
|
|
class ProcResGroup<list<ProcResource> resources> : ProcResourceKind {
|
|
list<ProcResource> Resources = resources;
|
|
SchedMachineModel SchedModel = ?;
|
|
int BufferSize = -1;
|
|
}
|
|
|
|
// A target architecture may define SchedReadWrite types and associate
|
|
// them with instruction operands.
|
|
class SchedReadWrite;
|
|
|
|
// List the per-operand types that map to the machine model of an
|
|
// instruction. One SchedWrite type must be listed for each explicit
|
|
// def operand in order. Additional SchedWrite types may optionally be
|
|
// listed for implicit def operands. SchedRead types may optionally
|
|
// be listed for use operands in order. The order of defs relative to
|
|
// uses is insignificant. This way, the same SchedReadWrite list may
|
|
// be used for multiple forms of an operation. For example, a
|
|
// two-address instruction could have two tied operands or single
|
|
// operand that both reads and writes a reg. In both cases we have a
|
|
// single SchedWrite and single SchedRead in any order.
|
|
class Sched<list<SchedReadWrite> schedrw> {
|
|
list<SchedReadWrite> SchedRW = schedrw;
|
|
}
|
|
|
|
// Define a scheduler resource associated with a def operand.
|
|
class SchedWrite : SchedReadWrite;
|
|
def NoWrite : SchedWrite;
|
|
|
|
// Define a scheduler resource associated with a use operand.
|
|
class SchedRead : SchedReadWrite;
|
|
|
|
// Define a SchedWrite that is modeled as a sequence of other
|
|
// SchedWrites with additive latency. This allows a single operand to
|
|
// be mapped the resources composed from a set of previously defined
|
|
// SchedWrites.
|
|
//
|
|
// If the final write in this sequence is a SchedWriteVariant marked
|
|
// Variadic, then the list of prior writes are distributed across all
|
|
// operands after resolving the predicate for the final write.
|
|
//
|
|
// SchedModel silences warnings but is ignored.
|
|
class WriteSequence<list<SchedWrite> writes, int rep = 1> : SchedWrite {
|
|
list<SchedWrite> Writes = writes;
|
|
int Repeat = rep;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Define values common to WriteRes and SchedWriteRes.
|
|
//
|
|
// SchedModel ties these resources to a processor.
|
|
class ProcWriteResources<list<ProcResourceKind> resources> {
|
|
list<ProcResourceKind> ProcResources = resources;
|
|
list<int> ResourceCycles = [];
|
|
int Latency = 1;
|
|
int NumMicroOps = 1;
|
|
bit BeginGroup = 0;
|
|
bit EndGroup = 0;
|
|
// Allow a processor to mark some scheduling classes as unsupported
|
|
// for stronger verification.
|
|
bit Unsupported = 0;
|
|
// Allow a processor to mark some scheduling classes as single-issue.
|
|
// SingleIssue is an alias for Begin/End Group.
|
|
bit SingleIssue = 0;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Define the resources and latency of a SchedWrite. This will be used
|
|
// directly by targets that have no itinerary classes. In this case,
|
|
// SchedWrite is defined by the target, while WriteResources is
|
|
// defined by the subtarget, and maps the SchedWrite to processor
|
|
// resources.
|
|
//
|
|
// If a target already has itinerary classes, SchedWriteResources can
|
|
// be used instead to define subtarget specific SchedWrites and map
|
|
// them to processor resources in one place. Then ItinRW can map
|
|
// itinerary classes to the subtarget's SchedWrites.
|
|
//
|
|
// ProcResources indicates the set of resources consumed by the write.
|
|
// Optionally, ResourceCycles indicates the number of cycles the
|
|
// resource is consumed. Each ResourceCycles item is paired with the
|
|
// ProcResource item at the same position in its list. ResourceCycles
|
|
// can be `[]`: in that case, all resources are consumed for a single
|
|
// cycle, regardless of latency, which models a fully pipelined processing
|
|
// unit. A value of 0 for ResourceCycles means that the resource must
|
|
// be available but is not consumed, which is only relevant for
|
|
// unbuffered resources.
|
|
//
|
|
// By default, each SchedWrite takes one micro-op, which is counted
|
|
// against the processor's IssueWidth limit. If an instruction can
|
|
// write multiple registers with a single micro-op, the subtarget
|
|
// should define one of the writes to be zero micro-ops. If a
|
|
// subtarget requires multiple micro-ops to write a single result, it
|
|
// should either override the write's NumMicroOps to be greater than 1
|
|
// or require additional writes. Extra writes can be required either
|
|
// by defining a WriteSequence, or simply listing extra writes in the
|
|
// instruction's list of writers beyond the number of "def"
|
|
// operands. The scheduler assumes that all micro-ops must be
|
|
// dispatched in the same cycle. These micro-ops may be required to
|
|
// begin or end the current dispatch group.
|
|
class WriteRes<SchedWrite write, list<ProcResourceKind> resources>
|
|
: ProcWriteResources<resources> {
|
|
SchedWrite WriteType = write;
|
|
}
|
|
|
|
// Directly name a set of WriteResources defining a new SchedWrite
|
|
// type at the same time. This class is unaware of its SchedModel so
|
|
// must be referenced by InstRW or ItinRW.
|
|
class SchedWriteRes<list<ProcResourceKind> resources> : SchedWrite,
|
|
ProcWriteResources<resources>;
|
|
|
|
// Define values common to ReadAdvance and SchedReadAdvance.
|
|
//
|
|
// SchedModel ties these resources to a processor.
|
|
class ProcReadAdvance<int cycles, list<SchedWrite> writes = []> {
|
|
int Cycles = cycles;
|
|
list<SchedWrite> ValidWrites = writes;
|
|
// Allow a processor to mark some scheduling classes as unsupported
|
|
// for stronger verification.
|
|
bit Unsupported = 0;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// A processor may define a ReadAdvance associated with a SchedRead
|
|
// to reduce latency of a prior write by N cycles. A negative advance
|
|
// effectively increases latency, which may be used for cross-domain
|
|
// stalls.
|
|
//
|
|
// A ReadAdvance may be associated with a list of SchedWrites
|
|
// to implement pipeline bypass. The Writes list may be empty to
|
|
// indicate operands that are always read this number of Cycles later
|
|
// than a normal register read, allowing the read's parent instruction
|
|
// to issue earlier relative to the writer.
|
|
class ReadAdvance<SchedRead read, int cycles, list<SchedWrite> writes = []>
|
|
: ProcReadAdvance<cycles, writes> {
|
|
SchedRead ReadType = read;
|
|
}
|
|
|
|
// Directly associate a new SchedRead type with a delay and optional
|
|
// pipeline bypass. For use with InstRW or ItinRW.
|
|
class SchedReadAdvance<int cycles, list<SchedWrite> writes = []> : SchedRead,
|
|
ProcReadAdvance<cycles, writes>;
|
|
|
|
// Define SchedRead defaults. Reads seldom need special treatment.
|
|
def ReadDefault : SchedRead;
|
|
def NoReadAdvance : SchedReadAdvance<0>;
|
|
|
|
// Define shared code that will be in the same scope as all
|
|
// SchedPredicates. Available variables are:
|
|
// (const MachineInstr *MI, const TargetSchedModel *SchedModel)
|
|
class PredicateProlog<code c> {
|
|
code Code = c;
|
|
}
|
|
|
|
// Base class for scheduling predicates.
|
|
class SchedPredicateBase;
|
|
|
|
// A scheduling predicate whose logic is defined by a MCInstPredicate.
|
|
// This can directly be used by SchedWriteVariant definitions.
|
|
class MCSchedPredicate<MCInstPredicate P> : SchedPredicateBase {
|
|
MCInstPredicate Pred = P;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Define a predicate to determine which SchedVariant applies to a
|
|
// particular MachineInstr. The code snippet is used as an
|
|
// if-statement's expression. Available variables are MI, SchedModel,
|
|
// and anything defined in a PredicateProlog.
|
|
//
|
|
// SchedModel silences warnings but is ignored.
|
|
class SchedPredicate<code pred> : SchedPredicateBase {
|
|
SchedMachineModel SchedModel = ?;
|
|
code Predicate = pred;
|
|
}
|
|
def NoSchedPred : MCSchedPredicate<TruePred>;
|
|
|
|
// Associate a predicate with a list of SchedReadWrites. By default,
|
|
// the selected SchedReadWrites are still associated with a single
|
|
// operand and assumed to execute sequentially with additive
|
|
// latency. However, if the parent SchedWriteVariant or
|
|
// SchedReadVariant is marked "Variadic", then each Selected
|
|
// SchedReadWrite is mapped in place to the instruction's variadic
|
|
// operands. In this case, latency is not additive. If the current Variant
|
|
// is already part of a Sequence, then that entire chain leading up to
|
|
// the Variant is distributed over the variadic operands.
|
|
class SchedVar<SchedPredicateBase pred, list<SchedReadWrite> selected> {
|
|
SchedPredicateBase Predicate = pred;
|
|
list<SchedReadWrite> Selected = selected;
|
|
}
|
|
|
|
// SchedModel silences warnings but is ignored.
|
|
class SchedVariant<list<SchedVar> variants> {
|
|
list<SchedVar> Variants = variants;
|
|
bit Variadic = 0;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// A SchedWriteVariant is a single SchedWrite type that maps to a list
|
|
// of SchedWrite types under the conditions defined by its predicates.
|
|
//
|
|
// A Variadic write is expanded to cover multiple "def" operands. The
|
|
// SchedVariant's Expansion list is then interpreted as one write
|
|
// per-operand instead of the usual sequential writes feeding a single
|
|
// operand.
|
|
class SchedWriteVariant<list<SchedVar> variants> : SchedWrite,
|
|
SchedVariant<variants> {
|
|
}
|
|
|
|
// A SchedReadVariant is a single SchedRead type that maps to a list
|
|
// of SchedRead types under the conditions defined by its predicates.
|
|
//
|
|
// A Variadic write is expanded to cover multiple "readsReg" operands as
|
|
// explained above.
|
|
class SchedReadVariant<list<SchedVar> variants> : SchedRead,
|
|
SchedVariant<variants> {
|
|
}
|
|
|
|
// Map a set of opcodes to a list of SchedReadWrite types. This allows
|
|
// the subtarget to easily override specific operations.
|
|
//
|
|
// SchedModel ties this opcode mapping to a processor.
|
|
class InstRW<list<SchedReadWrite> rw, dag instrlist> {
|
|
list<SchedReadWrite> OperandReadWrites = rw;
|
|
dag Instrs = instrlist;
|
|
SchedMachineModel SchedModel = ?;
|
|
// Allow a subtarget to mark some instructions as unsupported.
|
|
bit Unsupported = 0;
|
|
}
|
|
|
|
// Map a set of itinerary classes to SchedReadWrite resources. This is
|
|
// used to bootstrap a target (e.g. ARM) when itineraries already
|
|
// exist and changing InstrInfo is undesirable.
|
|
//
|
|
// SchedModel ties this ItineraryClass mapping to a processor.
|
|
class ItinRW<list<SchedReadWrite> rw, list<InstrItinClass> iic> {
|
|
list<InstrItinClass> MatchedItinClasses = iic;
|
|
list<SchedReadWrite> OperandReadWrites = rw;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Alias a target-defined SchedReadWrite to a processor specific
|
|
// SchedReadWrite. This allows a subtarget to easily map a
|
|
// SchedReadWrite type onto a WriteSequence, SchedWriteVariant, or
|
|
// SchedReadVariant.
|
|
//
|
|
// SchedModel will usually be provided by surrounding let statement
|
|
// and ties this SchedAlias mapping to a processor.
|
|
class SchedAlias<SchedReadWrite match, SchedReadWrite alias> {
|
|
SchedReadWrite MatchRW = match;
|
|
SchedReadWrite AliasRW = alias;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Allow the definition of processor register files for register renaming
|
|
// purposes.
|
|
//
|
|
// Each processor register file declares:
|
|
// - The set of registers that can be renamed.
|
|
// - The number of physical registers which can be used for register renaming
|
|
// purpose.
|
|
// - The cost of a register rename.
|
|
//
|
|
// The cost of a rename is the number of physical registers allocated by the
|
|
// register alias table to map the new definition. By default, register can be
|
|
// renamed at the cost of a single physical register. Note that register costs
|
|
// are defined at register class granularity (see field `Costs`).
|
|
//
|
|
// The set of registers that are subject to register renaming is declared using
|
|
// a list of register classes (see field `RegClasses`). An empty list of
|
|
// register classes means: all the logical registers defined by the target can
|
|
// be fully renamed.
|
|
//
|
|
// A register R can be renamed if its register class appears in the `RegClasses`
|
|
// set. When R is written, a new alias is allocated at the cost of one or more
|
|
// physical registers; as a result, false dependencies on R are removed.
|
|
//
|
|
// A sub-register V of register R is implicitly part of the same register file.
|
|
// However, V is only renamed if its register class is part of `RegClasses`.
|
|
// Otherwise, the processor keeps it (as well as any other different part
|
|
// of R) together with R, and a write of V always causes a compulsory read of R.
|
|
//
|
|
// This is what happens for example on AMD processors (at least from Bulldozer
|
|
// onwards), where AL and AH are not treated as independent from AX, and AX is
|
|
// not treated as independent from EAX. A write to AL has an implicity false
|
|
// dependency on the last write to EAX (or a portion of EAX). As a consequence,
|
|
// a write to AL cannot go in parallel with a write to AH.
|
|
//
|
|
// There is no false dependency if the partial register write belongs to a
|
|
// register class that is in `RegClasses`.
|
|
// There is also no penalty for writes that "clear the content a super-register"
|
|
// (see MC/MCInstrAnalysis.h - method MCInstrAnalysis::clearsSuperRegisters()).
|
|
// On x86-64, 32-bit GPR writes implicitly zero the upper half of the underlying
|
|
// physical register, effectively removing any false dependencies with the
|
|
// previous register definition.
|
|
//
|
|
// TODO: This implementation assumes that there is no limit in the number of
|
|
// renames per cycle, which might not be true for all hardware or register
|
|
// classes. Also, there is no limit to how many times the same logical register
|
|
// can be renamed during the same cycle.
|
|
//
|
|
// TODO: we don't currently model merge penalties for the case where a write to
|
|
// a part of a register is followed by a read from a larger part of the same
|
|
// register. On some Intel chips, different parts of a GPR can be stored in
|
|
// different physical registers. However, there is a cost to pay for when the
|
|
// partial write is combined with the previous super-register definition. We
|
|
// should add support for these cases, and correctly model merge problems with
|
|
// partial register accesses.
|
|
class RegisterFile<int numPhysRegs, list<RegisterClass> Classes = [],
|
|
list<int> Costs = []> {
|
|
list<RegisterClass> RegClasses = Classes;
|
|
list<int> RegCosts = Costs;
|
|
int NumPhysRegs = numPhysRegs;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Describe the retire control unit.
|
|
// A retire control unit specifies the size of the reorder buffer, as well as
|
|
// the maximum number of opcodes that can be retired every cycle.
|
|
// A value less-than-or-equal-to zero for field 'ReorderBufferSize' means: "the
|
|
// size is unknown". The idea is that external tools can fall-back to using
|
|
// field MicroOpBufferSize in SchedModel if the reorder buffer size is unknown.
|
|
// A zero or negative value for field 'MaxRetirePerCycle' means "no
|
|
// restrictions on the number of instructions retired per cycle".
|
|
// Models can optionally specify up to one instance of RetireControlUnit per
|
|
// scheduling model.
|
|
class RetireControlUnit<int bufferSize, int retirePerCycle> {
|
|
int ReorderBufferSize = bufferSize;
|
|
int MaxRetirePerCycle = retirePerCycle;
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Allow the definition of hardware counters.
|
|
class PfmCounter {
|
|
SchedMachineModel SchedModel = ?;
|
|
}
|
|
|
|
// Each processor can define how to measure cycles by defining a
|
|
// PfmCycleCounter.
|
|
class PfmCycleCounter<string counter> : PfmCounter {
|
|
string Counter = counter;
|
|
}
|
|
|
|
// Each ProcResourceUnits can define how to measure issued uops by defining
|
|
// a PfmIssueCounter.
|
|
class PfmIssueCounter<ProcResourceUnits resource, list<string> counters>
|
|
: PfmCounter{
|
|
// The resource units on which uops are issued.
|
|
ProcResourceUnits Resource = resource;
|
|
// The list of counters that measure issue events.
|
|
list<string> Counters = counters;
|
|
}
|