2012-07-07 04:00:00 +00:00
|
|
|
//===- CodeGenSchedule.h - Scheduling Machine Models ------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2012-07-07 04:00:00 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2014-01-24 17:20:08 +00:00
|
|
|
// This file defines structures to encapsulate the machine model as described in
|
2012-07-07 04:00:00 +00:00
|
|
|
// the target description.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-13 16:26:38 +00:00
|
|
|
#ifndef LLVM_UTILS_TABLEGEN_CODEGENSCHEDULE_H
|
|
|
|
#define LLVM_UTILS_TABLEGEN_CODEGENSCHEDULE_H
|
2012-07-07 04:00:00 +00:00
|
|
|
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
#include "llvm/ADT/APInt.h"
|
2012-07-07 04:00:00 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/StringMap.h"
|
2012-12-04 10:37:14 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/TableGen/Record.h"
|
2014-06-17 13:10:38 +00:00
|
|
|
#include "llvm/TableGen/SetTheory.h"
|
2012-07-07 04:00:00 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
class CodeGenTarget;
|
2012-09-15 00:19:57 +00:00
|
|
|
class CodeGenSchedModels;
|
|
|
|
class CodeGenInstruction;
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
class CodeGenRegisterClass;
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2017-09-13 10:31:10 +00:00
|
|
|
using RecVec = std::vector<Record*>;
|
|
|
|
using RecIter = std::vector<Record*>::const_iterator;
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2017-09-13 10:31:10 +00:00
|
|
|
using IdxVec = std::vector<unsigned>;
|
|
|
|
using IdxIter = std::vector<unsigned>::const_iterator;
|
2012-09-15 00:19:57 +00:00
|
|
|
|
|
|
|
/// We have two kinds of SchedReadWrites. Explicitly defined and inferred
|
|
|
|
/// sequences. TheDef is nonnull for explicit SchedWrites, but Sequence may or
|
|
|
|
/// may not be empty. TheDef is null for inferred sequences, and Sequence must
|
|
|
|
/// be nonempty.
|
|
|
|
///
|
|
|
|
/// IsVariadic controls whether the variants are expanded into multiple operands
|
|
|
|
/// or a sequence of writes on one operand.
|
|
|
|
struct CodeGenSchedRW {
|
2012-10-03 23:06:28 +00:00
|
|
|
unsigned Index;
|
2012-09-15 00:19:57 +00:00
|
|
|
std::string Name;
|
|
|
|
Record *TheDef;
|
2012-10-03 23:06:28 +00:00
|
|
|
bool IsRead;
|
2012-09-22 02:24:21 +00:00
|
|
|
bool IsAlias;
|
2012-09-15 00:19:57 +00:00
|
|
|
bool HasVariants;
|
|
|
|
bool IsVariadic;
|
|
|
|
bool IsSequence;
|
|
|
|
IdxVec Sequence;
|
2012-09-22 02:24:21 +00:00
|
|
|
RecVec Aliases;
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2012-12-20 01:05:39 +00:00
|
|
|
CodeGenSchedRW()
|
2014-04-16 04:21:27 +00:00
|
|
|
: Index(0), TheDef(nullptr), IsRead(false), IsAlias(false),
|
2012-12-20 01:05:39 +00:00
|
|
|
HasVariants(false), IsVariadic(false), IsSequence(false) {}
|
|
|
|
CodeGenSchedRW(unsigned Idx, Record *Def)
|
|
|
|
: Index(Idx), TheDef(Def), IsAlias(false), IsVariadic(false) {
|
2012-09-15 00:19:57 +00:00
|
|
|
Name = Def->getName();
|
2012-10-03 23:06:28 +00:00
|
|
|
IsRead = Def->isSubClassOf("SchedRead");
|
2012-09-15 00:19:57 +00:00
|
|
|
HasVariants = Def->isSubClassOf("SchedVariant");
|
|
|
|
if (HasVariants)
|
|
|
|
IsVariadic = Def->getValueAsBit("Variadic");
|
|
|
|
|
|
|
|
// Read records don't currently have sequences, but it can be easily
|
|
|
|
// added. Note that implicit Reads (from ReadVariant) may have a Sequence
|
|
|
|
// (but no record).
|
|
|
|
IsSequence = Def->isSubClassOf("WriteSequence");
|
|
|
|
}
|
|
|
|
|
2015-10-24 12:46:49 +00:00
|
|
|
CodeGenSchedRW(unsigned Idx, bool Read, ArrayRef<unsigned> Seq,
|
2012-12-20 01:05:39 +00:00
|
|
|
const std::string &Name)
|
2015-10-24 12:46:49 +00:00
|
|
|
: Index(Idx), Name(Name), TheDef(nullptr), IsRead(Read), IsAlias(false),
|
|
|
|
HasVariants(false), IsVariadic(false), IsSequence(true), Sequence(Seq) {
|
2012-09-15 00:19:57 +00:00
|
|
|
assert(Sequence.size() > 1 && "implied sequence needs >1 RWs");
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isValid() const {
|
|
|
|
assert((!HasVariants || TheDef) && "Variant write needs record def");
|
|
|
|
assert((!IsVariadic || HasVariants) && "Variadic write needs variants");
|
|
|
|
assert((!IsSequence || !HasVariants) && "Sequence can't have variant");
|
|
|
|
assert((!IsSequence || !Sequence.empty()) && "Sequence should be nonempty");
|
2012-09-22 02:24:21 +00:00
|
|
|
assert((!IsAlias || Aliases.empty()) && "Alias cannot have aliases");
|
2012-09-15 00:19:57 +00:00
|
|
|
return TheDef || !Sequence.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef NDEBUG
|
|
|
|
void dump() const;
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2012-09-18 04:03:30 +00:00
|
|
|
/// Represent a transition between SchedClasses induced by SchedVariant.
|
2012-09-15 00:19:59 +00:00
|
|
|
struct CodeGenSchedTransition {
|
|
|
|
unsigned ToClassIdx;
|
|
|
|
IdxVec ProcIndices;
|
|
|
|
RecVec PredTerm;
|
|
|
|
};
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
/// Scheduling class.
|
|
|
|
///
|
|
|
|
/// Each instruction description will be mapped to a scheduling class. There are
|
|
|
|
/// four types of classes:
|
|
|
|
///
|
|
|
|
/// 1) An explicitly defined itinerary class with ItinClassDef set.
|
|
|
|
/// Writes and ReadDefs are empty. ProcIndices contains 0 for any processor.
|
|
|
|
///
|
|
|
|
/// 2) An implied class with a list of SchedWrites and SchedReads that are
|
|
|
|
/// defined in an instruction definition and which are common across all
|
|
|
|
/// subtargets. ProcIndices contains 0 for any processor.
|
|
|
|
///
|
|
|
|
/// 3) An implied class with a list of InstRW records that map instructions to
|
|
|
|
/// SchedWrites and SchedReads per-processor. InstrClassMap should map the same
|
|
|
|
/// instructions to this class. ProcIndices contains all the processors that
|
|
|
|
/// provided InstrRW records for this class. ItinClassDef or Writes/Reads may
|
|
|
|
/// still be defined for processors with no InstRW entry.
|
|
|
|
///
|
|
|
|
/// 4) An inferred class represents a variant of another class that may be
|
|
|
|
/// resolved at runtime. ProcIndices contains the set of processors that may
|
|
|
|
/// require the class. ProcIndices are propagated through SchedClasses as
|
|
|
|
/// variants are expanded. Multiple SchedClasses may be inferred from an
|
|
|
|
/// itinerary class. Each inherits the processor index from the ItinRW record
|
|
|
|
/// that mapped the itinerary class to the variant Writes or Reads.
|
2012-07-07 04:00:00 +00:00
|
|
|
struct CodeGenSchedClass {
|
2013-03-16 18:58:55 +00:00
|
|
|
unsigned Index;
|
2012-07-07 04:00:00 +00:00
|
|
|
std::string Name;
|
|
|
|
Record *ItinClassDef;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
IdxVec Writes;
|
|
|
|
IdxVec Reads;
|
|
|
|
// Sorted list of ProcIdx, where ProcIdx==0 implies any processor.
|
|
|
|
IdxVec ProcIndices;
|
|
|
|
|
2012-09-15 00:19:59 +00:00
|
|
|
std::vector<CodeGenSchedTransition> Transitions;
|
|
|
|
|
2012-09-22 02:24:21 +00:00
|
|
|
// InstRW records associated with this class. These records may refer to an
|
|
|
|
// Instruction no longer mapped to this class by InstrClassMap. These
|
|
|
|
// Instructions should be ignored by this class because they have been split
|
|
|
|
// off to join another inferred class.
|
2012-09-15 00:19:57 +00:00
|
|
|
RecVec InstRWs;
|
|
|
|
|
2018-03-22 06:15:08 +00:00
|
|
|
CodeGenSchedClass(unsigned Index, std::string Name, Record *ItinClassDef)
|
|
|
|
: Index(Index), Name(std::move(Name)), ItinClassDef(ItinClassDef) {}
|
2013-03-16 18:58:55 +00:00
|
|
|
|
2018-03-21 17:57:21 +00:00
|
|
|
bool isKeyEqual(Record *IC, ArrayRef<unsigned> W,
|
|
|
|
ArrayRef<unsigned> R) const {
|
2015-10-24 12:46:49 +00:00
|
|
|
return ItinClassDef == IC && makeArrayRef(Writes) == W &&
|
|
|
|
makeArrayRef(Reads) == R;
|
2012-07-07 04:00:00 +00:00
|
|
|
}
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
// Is this class generated from a variants if existing classes? Instructions
|
|
|
|
// are never mapped directly to inferred scheduling classes.
|
|
|
|
bool isInferred() const { return !ItinClassDef; }
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
#ifndef NDEBUG
|
|
|
|
void dump(const CodeGenSchedModels *SchedModels) const;
|
|
|
|
#endif
|
2012-07-07 04:00:00 +00:00
|
|
|
};
|
|
|
|
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
/// Represent the cost of allocating a register of register class RCDef.
|
|
|
|
///
|
|
|
|
/// The cost of allocating a register is equivalent to the number of physical
|
|
|
|
/// registers used by the register renamer. Register costs are defined at
|
|
|
|
/// register class granularity.
|
|
|
|
struct CodeGenRegisterCost {
|
|
|
|
Record *RCDef;
|
|
|
|
unsigned Cost;
|
[tblgen][llvm-mca] Add the ability to describe move elimination candidates via tablegen.
This patch adds the ability to identify instructions that are "move elimination
candidates". It also allows scheduling models to describe processor register
files that allow move elimination.
A move elimination candidate is an instruction that can be eliminated at
register renaming stage.
Each subtarget can specify which instructions are move elimination candidates
with the help of tablegen class "IsOptimizableRegisterMove" (see
llvm/Target/TargetInstrPredicate.td).
For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated.
The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this:
```
def : IsOptimizableRegisterMove<[
InstructionEquivalenceClass<[
// GPR variants.
MOV32rr, MOV64rr,
// MMX variants.
MMX_MOVQ64rr,
// SSE variants.
MOVAPSrr, MOVUPSrr,
MOVAPDrr, MOVUPDrr,
MOVDQArr, MOVDQUrr,
// AVX variants.
VMOVAPSrr, VMOVUPSrr,
VMOVAPDrr, VMOVUPDrr,
VMOVDQArr, VMOVDQUrr
], CheckNot<CheckSameRegOperand<0, 1>> >
]>;
```
Definitions of IsOptimizableRegisterMove from processor models of a same
Target are processed by the SubtargetEmitter to auto-generate a target-specific
override for each of the following predicate methods:
```
bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI)
const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned
CPUID) const;
```
By default, those methods return false (i.e. conservatively assume that there
are no move elimination candidates).
Tablegen class RegisterFile has been extended with the following information:
- The set of register classes that allow move elimination.
- Maxium number of moves that can be eliminated every cycle.
- Whether move elimination is restricted to moves from registers that are
known to be zero.
This patch is structured in three part:
A first part (which is mostly boilerplate) adds the new
'isOptimizableRegisterMove' target hooks, and extends existing register file
descriptors in MC by introducing new fields to describe properties related to
move elimination.
A second part, uses the new tablegen constructs to describe move elimination in
the BtVer2 scheduling model.
A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove'
hook to mark instructions that are candidates for move elimination. It also
teaches class RegisterFile how to describe constraints on move elimination at
PRF granularity.
llvm-mca tests for btver2 show differences before/after this patch.
Differential Revision: https://reviews.llvm.org/D53134
llvm-svn: 344334
2018-10-12 11:23:04 +00:00
|
|
|
bool AllowMoveElimination;
|
|
|
|
CodeGenRegisterCost(Record *RC, unsigned RegisterCost, bool AllowMoveElim = false)
|
|
|
|
: RCDef(RC), Cost(RegisterCost), AllowMoveElimination(AllowMoveElim) {}
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
CodeGenRegisterCost(const CodeGenRegisterCost &) = default;
|
|
|
|
CodeGenRegisterCost &operator=(const CodeGenRegisterCost &) = delete;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// A processor register file.
|
|
|
|
///
|
|
|
|
/// This class describes a processor register file. Register file information is
|
|
|
|
/// currently consumed by external tools like llvm-mca to predict dispatch
|
|
|
|
/// stalls due to register pressure.
|
|
|
|
struct CodeGenRegisterFile {
|
|
|
|
std::string Name;
|
|
|
|
Record *RegisterFileDef;
|
[tblgen][llvm-mca] Add the ability to describe move elimination candidates via tablegen.
This patch adds the ability to identify instructions that are "move elimination
candidates". It also allows scheduling models to describe processor register
files that allow move elimination.
A move elimination candidate is an instruction that can be eliminated at
register renaming stage.
Each subtarget can specify which instructions are move elimination candidates
with the help of tablegen class "IsOptimizableRegisterMove" (see
llvm/Target/TargetInstrPredicate.td).
For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated.
The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this:
```
def : IsOptimizableRegisterMove<[
InstructionEquivalenceClass<[
// GPR variants.
MOV32rr, MOV64rr,
// MMX variants.
MMX_MOVQ64rr,
// SSE variants.
MOVAPSrr, MOVUPSrr,
MOVAPDrr, MOVUPDrr,
MOVDQArr, MOVDQUrr,
// AVX variants.
VMOVAPSrr, VMOVUPSrr,
VMOVAPDrr, VMOVUPDrr,
VMOVDQArr, VMOVDQUrr
], CheckNot<CheckSameRegOperand<0, 1>> >
]>;
```
Definitions of IsOptimizableRegisterMove from processor models of a same
Target are processed by the SubtargetEmitter to auto-generate a target-specific
override for each of the following predicate methods:
```
bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI)
const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned
CPUID) const;
```
By default, those methods return false (i.e. conservatively assume that there
are no move elimination candidates).
Tablegen class RegisterFile has been extended with the following information:
- The set of register classes that allow move elimination.
- Maxium number of moves that can be eliminated every cycle.
- Whether move elimination is restricted to moves from registers that are
known to be zero.
This patch is structured in three part:
A first part (which is mostly boilerplate) adds the new
'isOptimizableRegisterMove' target hooks, and extends existing register file
descriptors in MC by introducing new fields to describe properties related to
move elimination.
A second part, uses the new tablegen constructs to describe move elimination in
the BtVer2 scheduling model.
A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove'
hook to mark instructions that are candidates for move elimination. It also
teaches class RegisterFile how to describe constraints on move elimination at
PRF granularity.
llvm-mca tests for btver2 show differences before/after this patch.
Differential Revision: https://reviews.llvm.org/D53134
llvm-svn: 344334
2018-10-12 11:23:04 +00:00
|
|
|
unsigned MaxMovesEliminatedPerCycle;
|
|
|
|
bool AllowZeroMoveEliminationOnly;
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
|
|
|
|
unsigned NumPhysRegs;
|
|
|
|
std::vector<CodeGenRegisterCost> Costs;
|
|
|
|
|
[tblgen][llvm-mca] Add the ability to describe move elimination candidates via tablegen.
This patch adds the ability to identify instructions that are "move elimination
candidates". It also allows scheduling models to describe processor register
files that allow move elimination.
A move elimination candidate is an instruction that can be eliminated at
register renaming stage.
Each subtarget can specify which instructions are move elimination candidates
with the help of tablegen class "IsOptimizableRegisterMove" (see
llvm/Target/TargetInstrPredicate.td).
For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated.
The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this:
```
def : IsOptimizableRegisterMove<[
InstructionEquivalenceClass<[
// GPR variants.
MOV32rr, MOV64rr,
// MMX variants.
MMX_MOVQ64rr,
// SSE variants.
MOVAPSrr, MOVUPSrr,
MOVAPDrr, MOVUPDrr,
MOVDQArr, MOVDQUrr,
// AVX variants.
VMOVAPSrr, VMOVUPSrr,
VMOVAPDrr, VMOVUPDrr,
VMOVDQArr, VMOVDQUrr
], CheckNot<CheckSameRegOperand<0, 1>> >
]>;
```
Definitions of IsOptimizableRegisterMove from processor models of a same
Target are processed by the SubtargetEmitter to auto-generate a target-specific
override for each of the following predicate methods:
```
bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI)
const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned
CPUID) const;
```
By default, those methods return false (i.e. conservatively assume that there
are no move elimination candidates).
Tablegen class RegisterFile has been extended with the following information:
- The set of register classes that allow move elimination.
- Maxium number of moves that can be eliminated every cycle.
- Whether move elimination is restricted to moves from registers that are
known to be zero.
This patch is structured in three part:
A first part (which is mostly boilerplate) adds the new
'isOptimizableRegisterMove' target hooks, and extends existing register file
descriptors in MC by introducing new fields to describe properties related to
move elimination.
A second part, uses the new tablegen constructs to describe move elimination in
the BtVer2 scheduling model.
A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove'
hook to mark instructions that are candidates for move elimination. It also
teaches class RegisterFile how to describe constraints on move elimination at
PRF granularity.
llvm-mca tests for btver2 show differences before/after this patch.
Differential Revision: https://reviews.llvm.org/D53134
llvm-svn: 344334
2018-10-12 11:23:04 +00:00
|
|
|
CodeGenRegisterFile(StringRef name, Record *def, unsigned MaxMoveElimPerCy = 0,
|
|
|
|
bool AllowZeroMoveElimOnly = false)
|
|
|
|
: Name(name), RegisterFileDef(def),
|
|
|
|
MaxMovesEliminatedPerCycle(MaxMoveElimPerCy),
|
|
|
|
AllowZeroMoveEliminationOnly(AllowZeroMoveElimOnly),
|
|
|
|
NumPhysRegs(0) {}
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
|
|
|
|
bool hasDefaultCosts() const { return Costs.empty(); }
|
|
|
|
};
|
|
|
|
|
2012-07-07 04:00:00 +00:00
|
|
|
// Processor model.
|
|
|
|
//
|
|
|
|
// ModelName is a unique name used to name an instantiation of MCSchedModel.
|
|
|
|
//
|
|
|
|
// ModelDef is NULL for inferred Models. This happens when a processor defines
|
2014-01-24 17:20:08 +00:00
|
|
|
// an itinerary but no machine model. If the processor defines neither a machine
|
2012-07-07 04:00:00 +00:00
|
|
|
// model nor itinerary, then ModelDef remains pointing to NoModel. NoModel has
|
|
|
|
// the special "NoModel" field set to true.
|
|
|
|
//
|
|
|
|
// ItinsDef always points to a valid record definition, but may point to the
|
|
|
|
// default NoItineraries. NoItineraries has an empty list of InstrItinData
|
|
|
|
// records.
|
|
|
|
//
|
|
|
|
// ItinDefList orders this processor's InstrItinData records by SchedClass idx.
|
|
|
|
struct CodeGenProcModel {
|
2012-09-15 00:19:57 +00:00
|
|
|
unsigned Index;
|
2012-07-07 04:00:00 +00:00
|
|
|
std::string ModelName;
|
|
|
|
Record *ModelDef;
|
|
|
|
Record *ItinsDef;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
// Derived members...
|
|
|
|
|
|
|
|
// Array of InstrItinData records indexed by a CodeGenSchedClass index.
|
|
|
|
// This list is empty if the Processor has no value for Itineraries.
|
|
|
|
// Initialized by collectProcItins().
|
|
|
|
RecVec ItinDefList;
|
|
|
|
|
|
|
|
// Map itinerary classes to per-operand resources.
|
|
|
|
// This list is empty if no ItinRW refers to this Processor.
|
|
|
|
RecVec ItinRWDefs;
|
|
|
|
|
2016-06-24 08:43:27 +00:00
|
|
|
// List of unsupported feature.
|
|
|
|
// This list is empty if the Processor has no UnsupportedFeatures.
|
|
|
|
RecVec UnsupportedFeaturesDefs;
|
|
|
|
|
2012-09-15 00:20:02 +00:00
|
|
|
// All read/write resources associated with this processor.
|
|
|
|
RecVec WriteResDefs;
|
|
|
|
RecVec ReadAdvanceDefs;
|
|
|
|
|
|
|
|
// Per-operand machine model resources associated with this processor.
|
|
|
|
RecVec ProcResourceDefs;
|
|
|
|
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
// List of Register Files.
|
|
|
|
std::vector<CodeGenRegisterFile> RegisterFiles;
|
|
|
|
|
2018-04-05 15:41:41 +00:00
|
|
|
// Optional Retire Control Unit definition.
|
|
|
|
Record *RetireControlUnit;
|
|
|
|
|
[llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666).
This patch adds the ability to specify via tablegen which processor resources
are load/store queue resources.
A new tablegen class named MemoryQueue can be optionally used to mark resources
that model load/store queues. Information about the load/store queue is
collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to
initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and
`StoreQueueID`. Those two fields are identifiers for buffered resources used to
describe the load queue and the store queue.
Field `BufferSize` is interpreted as the number of entries in the queue, while
the number of units is a throughput indicator (i.e. number of available pickers
for loads/stores).
At construction time, LSUnit in llvm-mca checks for the presence of extra
processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If
that information is available, and fields LoadQueueID and StoreQueueID are set
to a value different than zero (i.e. the invalid processor resource index), then
LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value
declared by the two processor resources.
With this patch, we more accurately track dynamic dispatch stalls caused by the
lack of LS tokens (i.e. load/store queue full). This is also shown by the
differences in two BdVer2 tests. Stalls that were previously classified as
generic SCHEDULER FULL stalls, are not correctly classified either as "load
queue full" or "store queue full".
About the differences in the -scheduler-stats view: those differences are
expected, because entries in the load/store queue are not released at
instruction issue stage. Instead, those are released at instruction executed
stage. This is the main reason why for the modified tests, the load/store
queues gets full before PdEx is full.
Differential Revision: https://reviews.llvm.org/D54957
llvm-svn: 347857
2018-11-29 12:15:56 +00:00
|
|
|
// Load/Store queue descriptors.
|
|
|
|
Record *LoadQueue;
|
|
|
|
Record *StoreQueue;
|
|
|
|
|
2018-03-22 06:15:08 +00:00
|
|
|
CodeGenProcModel(unsigned Idx, std::string Name, Record *MDef,
|
2012-09-15 00:19:57 +00:00
|
|
|
Record *IDef) :
|
2018-04-05 15:41:41 +00:00
|
|
|
Index(Idx), ModelName(std::move(Name)), ModelDef(MDef), ItinsDef(IDef),
|
[llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666).
This patch adds the ability to specify via tablegen which processor resources
are load/store queue resources.
A new tablegen class named MemoryQueue can be optionally used to mark resources
that model load/store queues. Information about the load/store queue is
collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to
initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and
`StoreQueueID`. Those two fields are identifiers for buffered resources used to
describe the load queue and the store queue.
Field `BufferSize` is interpreted as the number of entries in the queue, while
the number of units is a throughput indicator (i.e. number of available pickers
for loads/stores).
At construction time, LSUnit in llvm-mca checks for the presence of extra
processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If
that information is available, and fields LoadQueueID and StoreQueueID are set
to a value different than zero (i.e. the invalid processor resource index), then
LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value
declared by the two processor resources.
With this patch, we more accurately track dynamic dispatch stalls caused by the
lack of LS tokens (i.e. load/store queue full). This is also shown by the
differences in two BdVer2 tests. Stalls that were previously classified as
generic SCHEDULER FULL stalls, are not correctly classified either as "load
queue full" or "store queue full".
About the differences in the -scheduler-stats view: those differences are
expected, because entries in the load/store queue are not released at
instruction issue stage. Instead, those are released at instruction executed
stage. This is the main reason why for the modified tests, the load/store
queues gets full before PdEx is full.
Differential Revision: https://reviews.llvm.org/D54957
llvm-svn: 347857
2018-11-29 12:15:56 +00:00
|
|
|
RetireControlUnit(nullptr), LoadQueue(nullptr), StoreQueue(nullptr) {}
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
bool hasItineraries() const {
|
|
|
|
return !ItinsDef->getValueAsListOfDefs("IID").empty();
|
|
|
|
}
|
|
|
|
|
2012-09-15 00:20:02 +00:00
|
|
|
bool hasInstrSchedModel() const {
|
|
|
|
return !WriteResDefs.empty() || !ItinRWDefs.empty();
|
|
|
|
}
|
|
|
|
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
bool hasExtraProcessorInfo() const {
|
[llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666).
This patch adds the ability to specify via tablegen which processor resources
are load/store queue resources.
A new tablegen class named MemoryQueue can be optionally used to mark resources
that model load/store queues. Information about the load/store queue is
collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to
initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and
`StoreQueueID`. Those two fields are identifiers for buffered resources used to
describe the load queue and the store queue.
Field `BufferSize` is interpreted as the number of entries in the queue, while
the number of units is a throughput indicator (i.e. number of available pickers
for loads/stores).
At construction time, LSUnit in llvm-mca checks for the presence of extra
processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If
that information is available, and fields LoadQueueID and StoreQueueID are set
to a value different than zero (i.e. the invalid processor resource index), then
LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value
declared by the two processor resources.
With this patch, we more accurately track dynamic dispatch stalls caused by the
lack of LS tokens (i.e. load/store queue full). This is also shown by the
differences in two BdVer2 tests. Stalls that were previously classified as
generic SCHEDULER FULL stalls, are not correctly classified either as "load
queue full" or "store queue full".
About the differences in the -scheduler-stats view: those differences are
expected, because entries in the load/store queue are not released at
instruction issue stage. Instead, those are released at instruction executed
stage. This is the main reason why for the modified tests, the load/store
queues gets full before PdEx is full.
Differential Revision: https://reviews.llvm.org/D54957
llvm-svn: 347857
2018-11-29 12:15:56 +00:00
|
|
|
return RetireControlUnit || LoadQueue || StoreQueue ||
|
|
|
|
!RegisterFiles.empty();
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
}
|
|
|
|
|
2012-09-15 00:20:02 +00:00
|
|
|
unsigned getProcResourceIdx(Record *PRDef) const;
|
|
|
|
|
2016-06-24 08:43:27 +00:00
|
|
|
bool isUnsupported(const CodeGenInstruction &Inst) const;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
#ifndef NDEBUG
|
|
|
|
void dump() const;
|
|
|
|
#endif
|
2012-07-07 04:00:00 +00:00
|
|
|
};
|
|
|
|
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
/// Used to correlate instructions to MCInstPredicates specified by
|
|
|
|
/// InstructionEquivalentClass tablegen definitions.
|
|
|
|
///
|
|
|
|
/// Example: a XOR of a register with self, is a known zero-idiom for most
|
|
|
|
/// X86 processors.
|
|
|
|
///
|
|
|
|
/// Each processor can use a (potentially different) InstructionEquivalenceClass
|
|
|
|
/// definition to classify zero-idioms. That means, XORrr is likely to appear
|
|
|
|
/// in more than one equivalence class (where each class definition is
|
|
|
|
/// contributed by a different processor).
|
|
|
|
///
|
|
|
|
/// There is no guarantee that the same MCInstPredicate will be used to describe
|
|
|
|
/// equivalence classes that identify XORrr as a zero-idiom.
|
|
|
|
///
|
|
|
|
/// To be more specific, the requirements for being a zero-idiom XORrr may be
|
|
|
|
/// different for different processors.
|
|
|
|
///
|
|
|
|
/// Class PredicateInfo identifies a subset of processors that specify the same
|
|
|
|
/// requirements (i.e. same MCInstPredicate and OperandMask) for an instruction
|
|
|
|
/// opcode.
|
|
|
|
///
|
|
|
|
/// Back to the example. Field `ProcModelMask` will have one bit set for every
|
|
|
|
/// processor model that sees XORrr as a zero-idiom, and that specifies the same
|
|
|
|
/// set of constraints.
|
|
|
|
///
|
|
|
|
/// By construction, there can be multiple instances of PredicateInfo associated
|
|
|
|
/// with a same instruction opcode. For example, different processors may define
|
|
|
|
/// different constraints on the same opcode.
|
|
|
|
///
|
|
|
|
/// Field OperandMask can be used as an extra constraint.
|
|
|
|
/// It may be used to describe conditions that appy only to a subset of the
|
|
|
|
/// operands of a machine instruction, and the operands subset may not be the
|
|
|
|
/// same for all processor models.
|
|
|
|
struct PredicateInfo {
|
|
|
|
llvm::APInt ProcModelMask; // A set of processor model indices.
|
|
|
|
llvm::APInt OperandMask; // An operand mask.
|
|
|
|
const Record *Predicate; // MCInstrPredicate definition.
|
|
|
|
PredicateInfo(llvm::APInt CpuMask, llvm::APInt Operands, const Record *Pred)
|
|
|
|
: ProcModelMask(CpuMask), OperandMask(Operands), Predicate(Pred) {}
|
|
|
|
|
|
|
|
bool operator==(const PredicateInfo &Other) const {
|
|
|
|
return ProcModelMask == Other.ProcModelMask &&
|
|
|
|
OperandMask == Other.OperandMask && Predicate == Other.Predicate;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/// A collection of PredicateInfo objects.
|
|
|
|
///
|
|
|
|
/// There is at least one OpcodeInfo object for every opcode specified by a
|
|
|
|
/// TIPredicate definition.
|
|
|
|
class OpcodeInfo {
|
2018-09-19 17:54:01 +00:00
|
|
|
std::vector<PredicateInfo> Predicates;
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
|
|
|
|
OpcodeInfo(const OpcodeInfo &Other) = delete;
|
|
|
|
OpcodeInfo &operator=(const OpcodeInfo &Other) = delete;
|
|
|
|
|
|
|
|
public:
|
|
|
|
OpcodeInfo() = default;
|
|
|
|
OpcodeInfo &operator=(OpcodeInfo &&Other) = default;
|
|
|
|
OpcodeInfo(OpcodeInfo &&Other) = default;
|
|
|
|
|
|
|
|
ArrayRef<PredicateInfo> getPredicates() const { return Predicates; }
|
|
|
|
|
|
|
|
void addPredicateForProcModel(const llvm::APInt &CpuMask,
|
|
|
|
const llvm::APInt &OperandMask,
|
|
|
|
const Record *Predicate);
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Used to group together tablegen instruction definitions that are subject
|
|
|
|
/// to a same set of constraints (identified by an instance of OpcodeInfo).
|
|
|
|
class OpcodeGroup {
|
|
|
|
OpcodeInfo Info;
|
|
|
|
std::vector<const Record *> Opcodes;
|
|
|
|
|
|
|
|
OpcodeGroup(const OpcodeGroup &Other) = delete;
|
|
|
|
OpcodeGroup &operator=(const OpcodeGroup &Other) = delete;
|
|
|
|
|
|
|
|
public:
|
|
|
|
OpcodeGroup(OpcodeInfo &&OpInfo) : Info(std::move(OpInfo)) {}
|
|
|
|
OpcodeGroup(OpcodeGroup &&Other) = default;
|
|
|
|
|
|
|
|
void addOpcode(const Record *Opcode) {
|
|
|
|
assert(std::find(Opcodes.begin(), Opcodes.end(), Opcode) == Opcodes.end() &&
|
|
|
|
"Opcode already in set!");
|
|
|
|
Opcodes.push_back(Opcode);
|
|
|
|
}
|
|
|
|
|
|
|
|
ArrayRef<const Record *> getOpcodes() const { return Opcodes; }
|
|
|
|
const OpcodeInfo &getOpcodeInfo() const { return Info; }
|
|
|
|
};
|
|
|
|
|
|
|
|
/// An STIPredicateFunction descriptor used by tablegen backends to
|
|
|
|
/// auto-generate the body of a predicate function as a member of tablegen'd
|
|
|
|
/// class XXXGenSubtargetInfo.
|
|
|
|
class STIPredicateFunction {
|
|
|
|
const Record *FunctionDeclaration;
|
|
|
|
|
|
|
|
std::vector<const Record *> Definitions;
|
|
|
|
std::vector<OpcodeGroup> Groups;
|
|
|
|
|
|
|
|
STIPredicateFunction(const STIPredicateFunction &Other) = delete;
|
|
|
|
STIPredicateFunction &operator=(const STIPredicateFunction &Other) = delete;
|
|
|
|
|
|
|
|
public:
|
|
|
|
STIPredicateFunction(const Record *Rec) : FunctionDeclaration(Rec) {}
|
|
|
|
STIPredicateFunction(STIPredicateFunction &&Other) = default;
|
|
|
|
|
|
|
|
bool isCompatibleWith(const STIPredicateFunction &Other) const {
|
|
|
|
return FunctionDeclaration == Other.FunctionDeclaration;
|
|
|
|
}
|
|
|
|
|
|
|
|
void addDefinition(const Record *Def) { Definitions.push_back(Def); }
|
|
|
|
void addOpcode(const Record *OpcodeRec, OpcodeInfo &&Info) {
|
|
|
|
if (Groups.empty() ||
|
|
|
|
Groups.back().getOpcodeInfo().getPredicates() != Info.getPredicates())
|
|
|
|
Groups.emplace_back(std::move(Info));
|
|
|
|
Groups.back().addOpcode(OpcodeRec);
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef getName() const {
|
|
|
|
return FunctionDeclaration->getValueAsString("Name");
|
|
|
|
}
|
|
|
|
const Record *getDefaultReturnPredicate() const {
|
|
|
|
return FunctionDeclaration->getValueAsDef("DefaultReturnValue");
|
|
|
|
}
|
|
|
|
|
|
|
|
const Record *getDeclaration() const { return FunctionDeclaration; }
|
|
|
|
ArrayRef<const Record *> getDefinitions() const { return Definitions; }
|
|
|
|
ArrayRef<OpcodeGroup> getGroups() const { return Groups; }
|
|
|
|
};
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
/// Top level container for machine model data.
|
2012-07-07 04:00:00 +00:00
|
|
|
class CodeGenSchedModels {
|
|
|
|
RecordKeeper &Records;
|
|
|
|
const CodeGenTarget &Target;
|
|
|
|
|
2012-10-03 23:06:32 +00:00
|
|
|
// Map dag expressions to Instruction lists.
|
|
|
|
SetTheory Sets;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
// List of unique processor models.
|
|
|
|
std::vector<CodeGenProcModel> ProcModels;
|
|
|
|
|
|
|
|
// Map Processor's MachineModel or ProcItin to a CodeGenProcModel index.
|
2017-09-13 10:31:10 +00:00
|
|
|
using ProcModelMapTy = DenseMap<Record*, unsigned>;
|
2012-09-15 00:19:57 +00:00
|
|
|
ProcModelMapTy ProcModelMap;
|
|
|
|
|
|
|
|
// Per-operand SchedReadWrite types.
|
|
|
|
std::vector<CodeGenSchedRW> SchedWrites;
|
|
|
|
std::vector<CodeGenSchedRW> SchedReads;
|
|
|
|
|
2012-07-07 04:00:00 +00:00
|
|
|
// List of unique SchedClasses.
|
|
|
|
std::vector<CodeGenSchedClass> SchedClasses;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
// Any inferred SchedClass has an index greater than NumInstrSchedClassses.
|
|
|
|
unsigned NumInstrSchedClasses;
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2016-06-21 03:24:03 +00:00
|
|
|
RecVec ProcResourceDefs;
|
|
|
|
RecVec ProcResGroups;
|
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
// Map each instruction to its unique SchedClass index considering the
|
|
|
|
// combination of it's itinerary class, SchedRW list, and InstRW records.
|
2017-09-13 10:31:10 +00:00
|
|
|
using InstClassMapTy = DenseMap<Record*, unsigned>;
|
2012-09-15 00:19:57 +00:00
|
|
|
InstClassMapTy InstrClassMap;
|
2012-07-07 04:00:00 +00:00
|
|
|
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
std::vector<STIPredicateFunction> STIPredicates;
|
|
|
|
|
2012-07-07 04:00:00 +00:00
|
|
|
public:
|
|
|
|
CodeGenSchedModels(RecordKeeper& RK, const CodeGenTarget &TGT);
|
|
|
|
|
2014-04-18 02:09:04 +00:00
|
|
|
// iterator access to the scheduling classes.
|
2017-09-13 10:31:10 +00:00
|
|
|
using class_iterator = std::vector<CodeGenSchedClass>::iterator;
|
|
|
|
using const_class_iterator = std::vector<CodeGenSchedClass>::const_iterator;
|
2014-04-18 02:09:04 +00:00
|
|
|
class_iterator classes_begin() { return SchedClasses.begin(); }
|
|
|
|
const_class_iterator classes_begin() const { return SchedClasses.begin(); }
|
|
|
|
class_iterator classes_end() { return SchedClasses.end(); }
|
|
|
|
const_class_iterator classes_end() const { return SchedClasses.end(); }
|
|
|
|
iterator_range<class_iterator> classes() {
|
2015-12-06 05:08:07 +00:00
|
|
|
return make_range(classes_begin(), classes_end());
|
2014-04-18 02:09:04 +00:00
|
|
|
}
|
|
|
|
iterator_range<const_class_iterator> classes() const {
|
2015-12-06 05:08:07 +00:00
|
|
|
return make_range(classes_begin(), classes_end());
|
2014-04-18 02:09:04 +00:00
|
|
|
}
|
|
|
|
iterator_range<class_iterator> explicit_classes() {
|
2015-12-06 05:08:07 +00:00
|
|
|
return make_range(classes_begin(), classes_begin() + NumInstrSchedClasses);
|
2014-04-18 02:09:04 +00:00
|
|
|
}
|
|
|
|
iterator_range<const_class_iterator> explicit_classes() const {
|
2015-12-06 05:08:07 +00:00
|
|
|
return make_range(classes_begin(), classes_begin() + NumInstrSchedClasses);
|
2014-04-18 02:09:04 +00:00
|
|
|
}
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
Record *getModelOrItinDef(Record *ProcDef) const {
|
|
|
|
Record *ModelDef = ProcDef->getValueAsDef("SchedModel");
|
|
|
|
Record *ItinsDef = ProcDef->getValueAsDef("ProcItin");
|
|
|
|
if (!ItinsDef->getValueAsListOfDefs("IID").empty()) {
|
|
|
|
assert(ModelDef->getValueAsBit("NoModel")
|
|
|
|
&& "Itineraries must be defined within SchedMachineModel");
|
|
|
|
return ItinsDef;
|
|
|
|
}
|
|
|
|
return ModelDef;
|
|
|
|
}
|
|
|
|
|
|
|
|
const CodeGenProcModel &getModelForProc(Record *ProcDef) const {
|
|
|
|
Record *ModelDef = getModelOrItinDef(ProcDef);
|
|
|
|
ProcModelMapTy::const_iterator I = ProcModelMap.find(ModelDef);
|
|
|
|
assert(I != ProcModelMap.end() && "missing machine model");
|
|
|
|
return ProcModels[I->second];
|
|
|
|
}
|
|
|
|
|
2013-06-15 04:50:06 +00:00
|
|
|
CodeGenProcModel &getProcModel(Record *ModelDef) {
|
2012-09-15 00:19:57 +00:00
|
|
|
ProcModelMapTy::const_iterator I = ProcModelMap.find(ModelDef);
|
|
|
|
assert(I != ProcModelMap.end() && "missing machine model");
|
|
|
|
return ProcModels[I->second];
|
|
|
|
}
|
2013-06-15 04:50:06 +00:00
|
|
|
const CodeGenProcModel &getProcModel(Record *ModelDef) const {
|
|
|
|
return const_cast<CodeGenSchedModels*>(this)->getProcModel(ModelDef);
|
|
|
|
}
|
2012-09-15 00:19:57 +00:00
|
|
|
|
|
|
|
// Iterate over the unique processor models.
|
2017-09-13 10:31:10 +00:00
|
|
|
using ProcIter = std::vector<CodeGenProcModel>::const_iterator;
|
2012-09-15 00:19:57 +00:00
|
|
|
ProcIter procModelBegin() const { return ProcModels.begin(); }
|
|
|
|
ProcIter procModelEnd() const { return ProcModels.end(); }
|
2016-02-13 06:03:32 +00:00
|
|
|
ArrayRef<CodeGenProcModel> procModels() const { return ProcModels; }
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
// Return true if any processors have itineraries.
|
|
|
|
bool hasItineraries() const;
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
// Get a SchedWrite from its index.
|
|
|
|
const CodeGenSchedRW &getSchedWrite(unsigned Idx) const {
|
|
|
|
assert(Idx < SchedWrites.size() && "bad SchedWrite index");
|
|
|
|
assert(SchedWrites[Idx].isValid() && "invalid SchedWrite");
|
|
|
|
return SchedWrites[Idx];
|
|
|
|
}
|
|
|
|
// Get a SchedWrite from its index.
|
|
|
|
const CodeGenSchedRW &getSchedRead(unsigned Idx) const {
|
|
|
|
assert(Idx < SchedReads.size() && "bad SchedRead index");
|
|
|
|
assert(SchedReads[Idx].isValid() && "invalid SchedRead");
|
|
|
|
return SchedReads[Idx];
|
|
|
|
}
|
|
|
|
|
|
|
|
const CodeGenSchedRW &getSchedRW(unsigned Idx, bool IsRead) const {
|
|
|
|
return IsRead ? getSchedRead(Idx) : getSchedWrite(Idx);
|
|
|
|
}
|
2012-10-03 23:06:28 +00:00
|
|
|
CodeGenSchedRW &getSchedRW(Record *Def) {
|
2012-09-22 02:24:21 +00:00
|
|
|
bool IsRead = Def->isSubClassOf("SchedRead");
|
2012-10-03 23:06:28 +00:00
|
|
|
unsigned Idx = getSchedRWIdx(Def, IsRead);
|
2012-09-22 02:24:21 +00:00
|
|
|
return const_cast<CodeGenSchedRW&>(
|
|
|
|
IsRead ? getSchedRead(Idx) : getSchedWrite(Idx));
|
|
|
|
}
|
2018-04-26 12:56:26 +00:00
|
|
|
const CodeGenSchedRW &getSchedRW(Record *Def) const {
|
2012-10-03 23:06:28 +00:00
|
|
|
return const_cast<CodeGenSchedModels&>(*this).getSchedRW(Def);
|
2012-09-22 02:24:21 +00:00
|
|
|
}
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2018-04-26 12:56:26 +00:00
|
|
|
unsigned getSchedRWIdx(const Record *Def, bool IsRead) const;
|
2012-09-15 00:19:57 +00:00
|
|
|
|
2012-09-19 04:43:19 +00:00
|
|
|
// Return true if the given write record is referenced by a ReadAdvance.
|
|
|
|
bool hasReadOfWrite(Record *WriteDef) const;
|
|
|
|
|
2012-07-07 04:00:00 +00:00
|
|
|
// Get a SchedClass from its index.
|
2012-09-15 00:19:57 +00:00
|
|
|
CodeGenSchedClass &getSchedClass(unsigned Idx) {
|
|
|
|
assert(Idx < SchedClasses.size() && "bad SchedClass index");
|
|
|
|
return SchedClasses[Idx];
|
|
|
|
}
|
|
|
|
const CodeGenSchedClass &getSchedClass(unsigned Idx) const {
|
2012-07-07 04:00:00 +00:00
|
|
|
assert(Idx < SchedClasses.size() && "bad SchedClass index");
|
|
|
|
return SchedClasses[Idx];
|
|
|
|
}
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
// Get the SchedClass index for an instruction. Instructions with no
|
|
|
|
// itinerary, no SchedReadWrites, and no InstrReadWrites references return 0
|
|
|
|
// for NoItinerary.
|
|
|
|
unsigned getSchedClassIdx(const CodeGenInstruction &Inst) const;
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2017-09-13 10:31:10 +00:00
|
|
|
using SchedClassIter = std::vector<CodeGenSchedClass>::const_iterator;
|
2012-09-15 00:19:57 +00:00
|
|
|
SchedClassIter schedClassBegin() const { return SchedClasses.begin(); }
|
|
|
|
SchedClassIter schedClassEnd() const { return SchedClasses.end(); }
|
2016-02-13 06:03:32 +00:00
|
|
|
ArrayRef<CodeGenSchedClass> schedClasses() const { return SchedClasses; }
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
unsigned numInstrSchedClasses() const { return NumInstrSchedClasses; }
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
void findRWs(const RecVec &RWDefs, IdxVec &Writes, IdxVec &Reads) const;
|
|
|
|
void findRWs(const RecVec &RWDefs, IdxVec &RWs, bool IsRead) const;
|
2012-09-15 00:19:59 +00:00
|
|
|
void expandRWSequence(unsigned RWIdx, IdxVec &RWSeq, bool IsRead) const;
|
2012-10-03 23:06:28 +00:00
|
|
|
void expandRWSeqForProc(unsigned RWIdx, IdxVec &RWSeq, bool IsRead,
|
|
|
|
const CodeGenProcModel &ProcModel) const;
|
2012-07-07 04:00:00 +00:00
|
|
|
|
2015-10-24 12:46:49 +00:00
|
|
|
unsigned addSchedClass(Record *ItinDef, ArrayRef<unsigned> OperWrites,
|
|
|
|
ArrayRef<unsigned> OperReads,
|
|
|
|
ArrayRef<unsigned> ProcIndices);
|
2012-09-15 00:19:57 +00:00
|
|
|
|
|
|
|
unsigned findOrInsertRW(ArrayRef<unsigned> Seq, bool IsRead);
|
|
|
|
|
2017-11-21 21:33:52 +00:00
|
|
|
Record *findProcResUnits(Record *ProcResKind, const CodeGenProcModel &PM,
|
|
|
|
ArrayRef<SMLoc> Loc) const;
|
2012-09-15 00:20:02 +00:00
|
|
|
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
ArrayRef<STIPredicateFunction> getSTIPredicates() const {
|
|
|
|
return STIPredicates;
|
|
|
|
}
|
2012-09-15 00:19:57 +00:00
|
|
|
private:
|
|
|
|
void collectProcModels();
|
2012-07-07 04:00:00 +00:00
|
|
|
|
|
|
|
// Initialize a new processor model if it is unique.
|
|
|
|
void addProcModel(Record *ProcDef);
|
|
|
|
|
2012-09-15 00:19:57 +00:00
|
|
|
void collectSchedRW();
|
|
|
|
|
2015-10-24 12:46:49 +00:00
|
|
|
std::string genRWName(ArrayRef<unsigned> Seq, bool IsRead);
|
|
|
|
unsigned findRWForSequence(ArrayRef<unsigned> Seq, bool IsRead);
|
2012-09-15 00:19:57 +00:00
|
|
|
|
|
|
|
void collectSchedClasses();
|
|
|
|
|
2018-04-05 15:41:41 +00:00
|
|
|
void collectRetireControlUnits();
|
|
|
|
|
[MC][Tablegen] Allow the definition of processor register files in the scheduling model for llvm-mca
This patch allows the description of register files in processor scheduling
models. This addresses PR36662.
A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td.
Targets can optionally describe register files for their processors using that
class. In particular, class RegisterFile allows to specify:
- The total number of physical registers.
- Which target registers are accessible through the register file.
- The cost of allocating a register at register renaming stage.
Example (from this patch - see file X86/X86ScheduleBtVer2.td)
def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]>
Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar
(btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM
register definitions only cost 1 physical register.
The syntax allows to specify an empty set of register classes. An empty set of
register classes means: this register file models all the registers specified by
the Target. For each register class, users can specify an optional register
cost. By default, register costs default to 1. A value of 0 for the number of
physical registers means: "this register file has an unbounded number of
physical registers".
This patch is structured in two parts.
* Part 1 - MC/Tablegen *
A first part adds the tablegen definition of RegisterFile, and teaches the
SubtargetEmitter how to emit information related to register files.
Information about register files is accessible through an instance of
MCExtraProcessorInfo.
The idea behind this design is to logically partition the processor description
which is only used by external tools (like llvm-mca) from the processor
information used by the llvm machine schedulers.
I think that this design would make easier for targets to get rid of the extra
processor information if they don't want it.
* Part 2 - llvm-mca related *
The second part of this patch is related to changes to llvm-mca.
The main differences are:
1) class RegisterFile now needs to take into account the "cost of a register"
when allocating physical registers at register renaming stage.
2) Point 1. triggered a minor refactoring which lef to the removal of the
"maximum 32 register files" restriction.
3) The BackendStatistics view has been updated so that we can print out extra
details related to each register file implemented by the processor.
The effect of point 3. is also visible in tests register-files-[1..5].s.
Differential Revision: https://reviews.llvm.org/D44980
llvm-svn: 329067
2018-04-03 13:36:24 +00:00
|
|
|
void collectRegisterFiles();
|
|
|
|
|
2018-04-05 15:41:41 +00:00
|
|
|
void collectOptionalProcessorInfo();
|
|
|
|
|
2013-03-16 18:58:55 +00:00
|
|
|
std::string createSchedClassName(Record *ItinClassDef,
|
2015-10-24 12:46:49 +00:00
|
|
|
ArrayRef<unsigned> OperWrites,
|
|
|
|
ArrayRef<unsigned> OperReads);
|
2012-09-15 00:19:57 +00:00
|
|
|
std::string createSchedClassName(const RecVec &InstDefs);
|
|
|
|
void createInstRWClass(Record *InstRWDef);
|
|
|
|
|
|
|
|
void collectProcItins();
|
|
|
|
|
|
|
|
void collectProcItinRW();
|
2016-06-24 08:43:27 +00:00
|
|
|
|
|
|
|
void collectProcUnsupportedFeatures();
|
2012-09-15 00:19:59 +00:00
|
|
|
|
|
|
|
void inferSchedClasses();
|
|
|
|
|
2018-08-14 18:36:54 +00:00
|
|
|
void checkMCInstPredicates() const;
|
2018-09-11 17:28:43 +00:00
|
|
|
|
[TableGen][SubtargetEmitter] Add the ability for processor models to describe dependency breaking instructions.
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
2018-09-19 15:57:45 +00:00
|
|
|
void checkSTIPredicates() const;
|
|
|
|
|
|
|
|
void collectSTIPredicates();
|
|
|
|
|
[llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666).
This patch adds the ability to specify via tablegen which processor resources
are load/store queue resources.
A new tablegen class named MemoryQueue can be optionally used to mark resources
that model load/store queues. Information about the load/store queue is
collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to
initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and
`StoreQueueID`. Those two fields are identifiers for buffered resources used to
describe the load queue and the store queue.
Field `BufferSize` is interpreted as the number of entries in the queue, while
the number of units is a throughput indicator (i.e. number of available pickers
for loads/stores).
At construction time, LSUnit in llvm-mca checks for the presence of extra
processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If
that information is available, and fields LoadQueueID and StoreQueueID are set
to a value different than zero (i.e. the invalid processor resource index), then
LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value
declared by the two processor resources.
With this patch, we more accurately track dynamic dispatch stalls caused by the
lack of LS tokens (i.e. load/store queue full). This is also shown by the
differences in two BdVer2 tests. Stalls that were previously classified as
generic SCHEDULER FULL stalls, are not correctly classified either as "load
queue full" or "store queue full".
About the differences in the -scheduler-stats view: those differences are
expected, because entries in the load/store queue are not released at
instruction issue stage. Instead, those are released at instruction executed
stage. This is the main reason why for the modified tests, the load/store
queues gets full before PdEx is full.
Differential Revision: https://reviews.llvm.org/D54957
llvm-svn: 347857
2018-11-29 12:15:56 +00:00
|
|
|
void collectLoadStoreQueueInfo();
|
|
|
|
|
2016-03-01 20:03:21 +00:00
|
|
|
void checkCompleteness();
|
|
|
|
|
2015-10-24 12:46:49 +00:00
|
|
|
void inferFromRW(ArrayRef<unsigned> OperWrites, ArrayRef<unsigned> OperReads,
|
|
|
|
unsigned FromClassIdx, ArrayRef<unsigned> ProcIndices);
|
2012-09-15 00:19:59 +00:00
|
|
|
void inferFromItinClass(Record *ItinClassDef, unsigned FromClassIdx);
|
|
|
|
void inferFromInstRWs(unsigned SCIdx);
|
2012-09-15 00:20:02 +00:00
|
|
|
|
2013-04-23 23:45:14 +00:00
|
|
|
bool hasSuperGroup(RecVec &SubUnits, CodeGenProcModel &PM);
|
|
|
|
void verifyProcResourceGroups(CodeGenProcModel &PM);
|
|
|
|
|
2012-09-15 00:20:02 +00:00
|
|
|
void collectProcResources();
|
|
|
|
|
|
|
|
void collectItinProcResources(Record *ItinClassDef);
|
|
|
|
|
2012-10-10 05:43:13 +00:00
|
|
|
void collectRWResources(unsigned RWIdx, bool IsRead,
|
2015-10-24 12:46:49 +00:00
|
|
|
ArrayRef<unsigned> ProcIndices);
|
2012-10-10 05:43:13 +00:00
|
|
|
|
2015-10-24 12:46:49 +00:00
|
|
|
void collectRWResources(ArrayRef<unsigned> Writes, ArrayRef<unsigned> Reads,
|
|
|
|
ArrayRef<unsigned> ProcIndices);
|
2012-09-15 00:20:02 +00:00
|
|
|
|
2017-11-21 21:33:52 +00:00
|
|
|
void addProcResource(Record *ProcResourceKind, CodeGenProcModel &PM,
|
|
|
|
ArrayRef<SMLoc> Loc);
|
2012-09-15 00:20:02 +00:00
|
|
|
|
|
|
|
void addWriteRes(Record *ProcWriteResDef, unsigned PIdx);
|
|
|
|
|
|
|
|
void addReadAdvance(Record *ProcReadAdvanceDef, unsigned PIdx);
|
2012-07-07 04:00:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace llvm
|
|
|
|
|
|
|
|
#endif
|