2015-09-10 16:49:58 +00:00
|
|
|
//===- InstrInfoEmitter.cpp - Generate a Instruction Set Desc. --*- C++ -*-===//
|
2005-04-22 00:00:37 +00:00
|
|
|
//
|
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
|
2005-04-22 00:00:37 +00:00
|
|
|
//
|
2003-10-20 20:20:30 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2003-10-05 19:27:59 +00:00
|
|
|
//
|
|
|
|
// This tablegen backend is responsible for emitting a description of the target
|
|
|
|
// instruction set for the code generator.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2024-03-25 09:40:35 +01:00
|
|
|
#include "Basic/SequenceToOffsetTable.h"
|
|
|
|
#include "Common/CodeGenDAGPatterns.h"
|
|
|
|
#include "Common/CodeGenInstruction.h"
|
|
|
|
#include "Common/CodeGenSchedule.h"
|
|
|
|
#include "Common/CodeGenTarget.h"
|
|
|
|
#include "Common/PredicateExpander.h"
|
|
|
|
#include "Common/SubtargetFeatureInfo.h"
|
|
|
|
#include "Common/Types.h"
|
2012-12-04 10:37:14 +00:00
|
|
|
#include "TableGenBackends.h"
|
2016-12-12 22:23:53 +00:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2023-09-27 12:41:54 -07:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2009-08-24 03:52:50 +00:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2016-12-12 22:23:53 +00:00
|
|
|
#include "llvm/Support/Casting.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2012-10-25 20:33:17 +00:00
|
|
|
#include "llvm/TableGen/Error.h"
|
2012-06-11 15:37:55 +00:00
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
#include "llvm/TableGen/TableGenBackend.h"
|
2016-12-12 22:23:53 +00:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstdint>
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
#include <iterator>
|
2012-06-11 15:37:55 +00:00
|
|
|
#include <map>
|
2016-12-12 22:23:53 +00:00
|
|
|
#include <string>
|
|
|
|
#include <utility>
|
2012-06-11 15:37:55 +00:00
|
|
|
#include <vector>
|
2015-09-10 16:49:58 +00:00
|
|
|
|
2004-08-01 03:55:39 +00:00
|
|
|
using namespace llvm;
|
2003-11-11 22:41:34 +00:00
|
|
|
|
2022-06-29 00:59:01 -07:00
|
|
|
cl::OptionCategory InstrInfoEmitterCat("Options for -gen-instr-info");
|
|
|
|
static cl::opt<bool> ExpandMIOperandInfo(
|
|
|
|
"instr-info-expand-mi-operand-info",
|
|
|
|
cl::desc("Expand operand's MIOperandInfo DAG into suboperands"),
|
|
|
|
cl::cat(InstrInfoEmitterCat), cl::init(true));
|
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
namespace {
|
2016-12-12 22:23:53 +00:00
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
class InstrInfoEmitter {
|
2024-09-18 22:27:26 -07:00
|
|
|
const RecordKeeper &Records;
|
|
|
|
const CodeGenDAGPatterns CDP;
|
2012-07-07 04:00:00 +00:00
|
|
|
const CodeGenSchedModels &SchedModels;
|
2012-06-11 15:37:55 +00:00
|
|
|
|
|
|
|
public:
|
2024-09-18 22:27:26 -07:00
|
|
|
InstrInfoEmitter(const RecordKeeper &R)
|
2012-07-07 04:00:00 +00:00
|
|
|
: Records(R), CDP(R), SchedModels(CDP.getTargetInfo().getSchedModels()) {}
|
2012-06-11 15:37:55 +00:00
|
|
|
|
|
|
|
// run - Output the instruction set description.
|
|
|
|
void run(raw_ostream &OS);
|
|
|
|
|
|
|
|
private:
|
|
|
|
void emitEnums(raw_ostream &OS);
|
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
typedef std::vector<std::string> OperandInfoTy;
|
|
|
|
typedef std::vector<OperandInfoTy> OperandInfoListTy;
|
|
|
|
typedef std::map<OperandInfoTy, unsigned> OperandInfoMapTy;
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
|
|
|
/// The keys of this map are maps which have OpName enum values as their keys
|
|
|
|
/// and instruction operand indices as their values. The values of this map
|
|
|
|
/// are lists of instruction names.
|
|
|
|
typedef std::map<std::map<unsigned, unsigned>, std::vector<std::string>>
|
2016-12-12 22:23:53 +00:00
|
|
|
OpNameMapTy;
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
typedef std::map<std::string, unsigned>::iterator StrUintMapIter;
|
2018-05-25 15:55:37 +00:00
|
|
|
|
|
|
|
/// Generate member functions in the target-specific GenInstrInfo class.
|
|
|
|
///
|
|
|
|
/// This method is used to custom expand TIIPredicate definitions.
|
|
|
|
/// See file llvm/Target/TargetInstPredicates.td for a description of what is
|
|
|
|
/// a TIIPredicate and how to use it.
|
[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
2018-10-31 12:28:05 +00:00
|
|
|
void emitTIIHelperMethods(raw_ostream &OS, StringRef TargetName,
|
|
|
|
bool ExpandDefinition = true);
|
2018-05-25 16:02:43 +00:00
|
|
|
|
|
|
|
/// Expand TIIPredicate definitions to functions that accept a const MCInst
|
|
|
|
/// reference.
|
2018-08-14 18:36:54 +00:00
|
|
|
void emitMCIIHelperMethods(raw_ostream &OS, StringRef TargetName);
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
|
|
|
|
/// Write verifyInstructionPredicates methods.
|
|
|
|
void emitFeatureVerifier(raw_ostream &OS, const CodeGenTarget &Target);
|
2012-06-11 15:37:55 +00:00
|
|
|
void emitRecord(const CodeGenInstruction &Inst, unsigned Num,
|
2024-09-18 22:27:26 -07:00
|
|
|
const Record *InstrInfo,
|
|
|
|
std::map<std::vector<const Record *>, unsigned> &EL,
|
2023-01-12 21:02:23 +00:00
|
|
|
const OperandInfoMapTy &OperandInfo, raw_ostream &OS);
|
2019-07-16 22:10:16 +00:00
|
|
|
void emitOperandTypeMappings(
|
|
|
|
raw_ostream &OS, const CodeGenTarget &Target,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions);
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
void
|
2016-02-01 01:33:42 +00:00
|
|
|
initOperandMapData(ArrayRef<const CodeGenInstruction *> NumberedInstructions,
|
2017-07-07 06:22:35 +00:00
|
|
|
StringRef Namespace,
|
2014-02-05 07:27:49 +00:00
|
|
|
std::map<std::string, unsigned> &Operands,
|
|
|
|
OpNameMapTy &OperandMap);
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
void emitOperandNameMappings(
|
|
|
|
raw_ostream &OS, const CodeGenTarget &Target,
|
2016-02-01 01:33:42 +00:00
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions);
|
2012-06-11 15:37:55 +00:00
|
|
|
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
void emitLogicalOperandSizeMappings(
|
|
|
|
raw_ostream &OS, StringRef Namespace,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions);
|
|
|
|
void emitLogicalOperandTypeMappings(
|
|
|
|
raw_ostream &OS, StringRef Namespace,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions);
|
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
// Operand information.
|
2023-01-12 21:02:23 +00:00
|
|
|
unsigned CollectOperandInfo(OperandInfoListTy &OperandInfoList,
|
|
|
|
OperandInfoMapTy &OperandInfoMap);
|
|
|
|
void EmitOperandInfo(raw_ostream &OS, OperandInfoListTy &OperandInfoList);
|
|
|
|
OperandInfoTy GetOperandInfo(const CodeGenInstruction &Inst);
|
2012-06-11 15:37:55 +00:00
|
|
|
};
|
2016-12-12 22:23:53 +00:00
|
|
|
|
2015-09-10 16:49:58 +00:00
|
|
|
} // end anonymous namespace
|
2012-06-11 15:37:55 +00:00
|
|
|
|
2008-01-06 01:20:13 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Operand Info Emission.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
InstrInfoEmitter::OperandInfoTy
|
2006-11-06 23:49:51 +00:00
|
|
|
InstrInfoEmitter::GetOperandInfo(const CodeGenInstruction &Inst) {
|
2023-01-12 21:02:23 +00:00
|
|
|
OperandInfoTy Result;
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2014-04-18 02:09:07 +00:00
|
|
|
for (auto &Op : Inst.Operands) {
|
2006-11-10 02:01:40 +00:00
|
|
|
// Handle aggregate operands and normal operands the same way by expanding
|
|
|
|
// either case into a list of operands for this op.
|
2010-11-01 04:03:32 +00:00
|
|
|
std::vector<CGIOperandList::OperandInfo> OperandList;
|
2006-11-10 02:01:40 +00:00
|
|
|
|
|
|
|
// This might be a multiple operand thing. Targets like X86 have
|
|
|
|
// registers in their multi-operand operands. It may also be an anonymous
|
|
|
|
// operand, which has a single operand, but no declared class for the
|
|
|
|
// operand.
|
2024-09-18 22:27:26 -07:00
|
|
|
const DagInit *MIOI = Op.MIOperandInfo;
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
if (!MIOI || MIOI->getNumArgs() == 0) {
|
|
|
|
// Single, anonymous, operand.
|
2014-04-18 02:09:07 +00:00
|
|
|
OperandList.push_back(Op);
|
2005-11-19 07:05:57 +00:00
|
|
|
} else {
|
2014-04-18 02:09:07 +00:00
|
|
|
for (unsigned j = 0, e = Op.MINumOperands; j != e; ++j) {
|
|
|
|
OperandList.push_back(Op);
|
2006-11-06 23:49:51 +00:00
|
|
|
|
2016-12-12 22:23:53 +00:00
|
|
|
auto *OpR = cast<DefInit>(MIOI->getArg(j))->getDef();
|
2006-11-10 02:01:40 +00:00
|
|
|
OperandList.back().Rec = OpR;
|
|
|
|
}
|
|
|
|
}
|
2006-11-06 23:53:31 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
for (unsigned j = 0, e = OperandList.size(); j != e; ++j) {
|
2024-09-09 14:33:21 -07:00
|
|
|
const Record *OpR = OperandList[j].Rec;
|
2006-11-10 02:01:40 +00:00
|
|
|
std::string Res;
|
2011-06-27 21:06:21 +00:00
|
|
|
|
|
|
|
if (OpR->isSubClassOf("RegisterOperand"))
|
|
|
|
OpR = OpR->getValueAsDef("RegClass");
|
2006-11-10 02:01:40 +00:00
|
|
|
if (OpR->isSubClassOf("RegisterClass"))
|
|
|
|
Res += getQualifiedName(OpR) + "RegClassID, ";
|
2009-07-29 21:10:12 +00:00
|
|
|
else if (OpR->isSubClassOf("PointerLikeRegClass"))
|
|
|
|
Res += utostr(OpR->getValueAsInt("RegClassKind")) + ", ";
|
2006-11-10 02:01:40 +00:00
|
|
|
else
|
2010-06-18 18:13:55 +00:00
|
|
|
// -1 means the operand does not have a fixed register class.
|
|
|
|
Res += "-1, ";
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
// Fill in applicable flags.
|
|
|
|
Res += "0";
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
// Ptr value whose register class is resolved via callback.
|
2009-07-29 20:43:05 +00:00
|
|
|
if (OpR->isSubClassOf("PointerLikeRegClass"))
|
2011-06-28 19:10:37 +00:00
|
|
|
Res += "|(1<<MCOI::LookupPtrRegClass)";
|
2006-11-10 02:01:40 +00:00
|
|
|
|
|
|
|
// Predicate operands. Check to see if the original unexpanded operand
|
2013-08-22 09:57:11 +00:00
|
|
|
// was of type PredicateOp.
|
2014-04-18 02:09:07 +00:00
|
|
|
if (Op.Rec->isSubClassOf("PredicateOp"))
|
2011-06-28 19:10:37 +00:00
|
|
|
Res += "|(1<<MCOI::Predicate)";
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2007-07-10 18:05:01 +00:00
|
|
|
// Optional def operands. Check to see if the original unexpanded operand
|
|
|
|
// was of type OptionalDefOperand.
|
2014-04-18 02:09:07 +00:00
|
|
|
if (Op.Rec->isSubClassOf("OptionalDefOperand"))
|
2011-06-28 19:10:37 +00:00
|
|
|
Res += "|(1<<MCOI::OptionalDef)";
|
2007-07-10 18:05:01 +00:00
|
|
|
|
2020-01-09 14:01:55 -05:00
|
|
|
// Branch target operands. Check to see if the original unexpanded
|
|
|
|
// operand was of type BranchTargetOperand.
|
|
|
|
if (Op.Rec->isSubClassOf("BranchTargetOperand"))
|
|
|
|
Res += "|(1<<MCOI::BranchTarget)";
|
|
|
|
|
2012-03-11 01:57:56 +00:00
|
|
|
// Fill in operand type.
|
2015-01-12 19:33:09 +00:00
|
|
|
Res += ", ";
|
2014-04-18 02:09:07 +00:00
|
|
|
assert(!Op.OperandType.empty() && "Invalid operand type.");
|
|
|
|
Res += Op.OperandType;
|
2012-03-11 01:57:56 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
// Fill in constraint info.
|
2010-02-10 01:45:28 +00:00
|
|
|
Res += ", ";
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2010-11-01 04:03:32 +00:00
|
|
|
const CGIOperandList::ConstraintInfo &Constraint = Op.Constraints[j];
|
2010-02-10 01:45:28 +00:00
|
|
|
if (Constraint.isNone())
|
|
|
|
Res += "0";
|
|
|
|
else if (Constraint.isEarlyClobber())
|
2020-12-15 12:47:27 -05:00
|
|
|
Res += "MCOI_EARLY_CLOBBER";
|
2010-02-10 01:45:28 +00:00
|
|
|
else {
|
|
|
|
assert(Constraint.isTied());
|
2020-12-15 12:47:27 -05:00
|
|
|
Res += "MCOI_TIED_TO(" + utostr(Constraint.getTiedOperand()) + ")";
|
2010-02-10 01:45:28 +00:00
|
|
|
}
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2006-11-10 02:01:40 +00:00
|
|
|
Result.push_back(Res);
|
2005-08-19 18:46:26 +00:00
|
|
|
}
|
|
|
|
}
|
2006-11-01 00:27:05 +00:00
|
|
|
|
2005-08-19 18:46:26 +00:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
unsigned
|
|
|
|
InstrInfoEmitter::CollectOperandInfo(OperandInfoListTy &OperandInfoList,
|
|
|
|
OperandInfoMapTy &OperandInfoMap) {
|
2008-01-06 01:20:13 +00:00
|
|
|
const CodeGenTarget &Target = CDP.getTargetInfo();
|
2023-01-12 21:02:23 +00:00
|
|
|
unsigned Offset = 0;
|
2016-01-17 20:38:18 +00:00
|
|
|
for (const CodeGenInstruction *Inst : Target.getInstructionsByEnumValue()) {
|
2023-01-12 21:02:23 +00:00
|
|
|
OperandInfoTy OperandInfo = GetOperandInfo(*Inst);
|
|
|
|
if (OperandInfoMap.insert({OperandInfo, Offset}).second) {
|
|
|
|
OperandInfoList.push_back(OperandInfo);
|
|
|
|
Offset += OperandInfo.size();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
void InstrInfoEmitter::EmitOperandInfo(raw_ostream &OS,
|
|
|
|
OperandInfoListTy &OperandInfoList) {
|
|
|
|
unsigned Offset = 0;
|
|
|
|
for (auto &OperandInfo : OperandInfoList) {
|
|
|
|
OS << " /* " << Offset << " */";
|
|
|
|
for (auto &Info : OperandInfo)
|
|
|
|
OS << " { " << Info << " },";
|
|
|
|
OS << '\n';
|
|
|
|
Offset += OperandInfo.size();
|
2008-01-06 01:20:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
/// Initialize data structures for generating operand name mappings.
|
2019-07-16 22:39:18 +00:00
|
|
|
///
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
/// \param Operands [out] A map used to generate the OpName enum with operand
|
|
|
|
/// names as its keys and operand enum values as its values.
|
|
|
|
/// \param OperandMap [out] A map for representing the operand name mappings for
|
|
|
|
/// each instructions. This is used to generate the OperandMap table as
|
|
|
|
/// well as the getNamedOperandIdx() function.
|
|
|
|
void InstrInfoEmitter::initOperandMapData(
|
2016-02-01 01:33:42 +00:00
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions,
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
StringRef Namespace, std::map<std::string, unsigned> &Operands,
|
|
|
|
OpNameMapTy &OperandMap) {
|
|
|
|
unsigned NumOperands = 0;
|
2014-04-18 02:09:07 +00:00
|
|
|
for (const CodeGenInstruction *Inst : NumberedInstructions) {
|
|
|
|
if (!Inst->TheDef->getValueAsBit("UseNamedOperandTable"))
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
continue;
|
|
|
|
std::map<unsigned, unsigned> OpList;
|
2014-04-18 02:09:07 +00:00
|
|
|
for (const auto &Info : Inst->Operands) {
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
StrUintMapIter I = Operands.find(Info.Name);
|
|
|
|
|
|
|
|
if (I == Operands.end()) {
|
|
|
|
I = Operands.insert(Operands.begin(), std::pair<std::string, unsigned>(
|
|
|
|
Info.Name, NumOperands++));
|
|
|
|
}
|
|
|
|
OpList[I->second] = Info.MIOperandNo;
|
|
|
|
}
|
2017-07-07 06:22:35 +00:00
|
|
|
OperandMap[OpList].push_back(Namespace.str() +
|
2016-12-04 05:48:16 +00:00
|
|
|
"::" + Inst->TheDef->getName().str());
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Generate a table and function for looking up the indices of operands by
|
|
|
|
/// name.
|
|
|
|
///
|
|
|
|
/// This code generates:
|
|
|
|
/// - An enum in the llvm::TargetNamespace::OpName namespace, with one entry
|
|
|
|
/// for each operand name.
|
|
|
|
/// - A 2-dimensional table called OperandMap for mapping OpName enum values to
|
|
|
|
/// operand indices.
|
|
|
|
/// - A function called getNamedOperandIdx(uint16_t Opcode, uint16_t NamedIdx)
|
|
|
|
/// for looking up the operand index for an instruction, given a value from
|
|
|
|
/// OpName enum
|
|
|
|
void InstrInfoEmitter::emitOperandNameMappings(
|
|
|
|
raw_ostream &OS, const CodeGenTarget &Target,
|
2016-02-01 01:33:42 +00:00
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions) {
|
2017-07-07 06:22:35 +00:00
|
|
|
StringRef Namespace = Target.getInstNamespace();
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
std::string OpNameNS = "OpName";
|
|
|
|
// Map of operand names to their enumeration value. This will be used to
|
|
|
|
// generate the OpName enum.
|
|
|
|
std::map<std::string, unsigned> Operands;
|
|
|
|
OpNameMapTy OperandMap;
|
|
|
|
|
|
|
|
initOperandMapData(NumberedInstructions, Namespace, Operands, OperandMap);
|
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_OPERAND_ENUM\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_OPERAND_ENUM\n";
|
2015-03-13 01:10:08 +00:00
|
|
|
OS << "namespace llvm {\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
OS << "namespace " << Namespace << " {\n";
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "namespace " << OpNameNS << " {\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
OS << "enum {\n";
|
2014-04-18 02:09:07 +00:00
|
|
|
for (const auto &Op : Operands)
|
|
|
|
OS << " " << Op.first << " = " << Op.second << ",\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
2020-11-06 14:19:59 +00:00
|
|
|
OS << " OPERAND_LAST";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
OS << "\n};\n";
|
2015-09-10 16:49:58 +00:00
|
|
|
OS << "} // end namespace OpName\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#endif //GET_INSTRINFO_OPERAND_ENUM\n\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_NAMED_OPS\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_NAMED_OPS\n";
|
2015-03-13 01:10:08 +00:00
|
|
|
OS << "namespace llvm {\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
OS << "namespace " << Namespace << " {\n";
|
2014-08-01 17:00:27 +00:00
|
|
|
OS << "LLVM_READONLY\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
OS << "int16_t getNamedOperandIdx(uint16_t Opcode, uint16_t NamedIdx) {\n";
|
2013-07-15 16:53:32 +00:00
|
|
|
if (!Operands.empty()) {
|
|
|
|
OS << " static const int16_t OperandMap [][" << Operands.size()
|
|
|
|
<< "] = {\n";
|
2014-04-18 02:09:07 +00:00
|
|
|
for (const auto &Entry : OperandMap) {
|
|
|
|
const std::map<unsigned, unsigned> &OpList = Entry.first;
|
2013-07-15 16:53:32 +00:00
|
|
|
OS << "{";
|
|
|
|
|
|
|
|
// Emit a row of the OperandMap table
|
2014-04-18 02:09:07 +00:00
|
|
|
for (unsigned i = 0, e = Operands.size(); i != e; ++i)
|
|
|
|
OS << (OpList.count(i) == 0 ? -1 : (int)OpList.find(i)->second) << ", ";
|
2013-07-15 16:53:32 +00:00
|
|
|
|
|
|
|
OS << "},\n";
|
|
|
|
}
|
|
|
|
OS << "};\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
2013-07-15 16:53:32 +00:00
|
|
|
OS << " switch(Opcode) {\n";
|
|
|
|
unsigned TableIndex = 0;
|
2014-04-18 02:09:07 +00:00
|
|
|
for (const auto &Entry : OperandMap) {
|
|
|
|
for (const std::string &Name : Entry.second)
|
|
|
|
OS << " case " << Name << ":\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
2013-07-15 16:53:32 +00:00
|
|
|
OS << " return OperandMap[" << TableIndex++ << "][NamedIdx];\n";
|
|
|
|
}
|
2020-11-06 14:19:59 +00:00
|
|
|
OS << " default: return -1;\n";
|
2013-07-15 16:53:32 +00:00
|
|
|
OS << " }\n";
|
|
|
|
} else {
|
|
|
|
// There are no operands, so no need to emit anything
|
|
|
|
OS << " return -1;\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
}
|
|
|
|
OS << "}\n";
|
2015-09-10 16:49:58 +00:00
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#endif //GET_INSTRINFO_NAMED_OPS\n\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
}
|
|
|
|
|
2013-11-17 21:24:41 +00:00
|
|
|
/// Generate an enum for all the operand types for this target, under the
|
|
|
|
/// llvm::TargetNamespace::OpTypes namespace.
|
|
|
|
/// Operand types are all definitions derived of the Operand Target.td class.
|
2019-07-16 22:10:16 +00:00
|
|
|
void InstrInfoEmitter::emitOperandTypeMappings(
|
|
|
|
raw_ostream &OS, const CodeGenTarget &Target,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions) {
|
2013-11-17 21:24:41 +00:00
|
|
|
|
2017-07-07 06:22:35 +00:00
|
|
|
StringRef Namespace = Target.getInstNamespace();
|
2024-09-18 22:27:26 -07:00
|
|
|
ArrayRef<const Record *> Operands =
|
|
|
|
Records.getAllDerivedDefinitions("Operand");
|
|
|
|
ArrayRef<const Record *> RegisterOperands =
|
2019-09-23 18:51:00 +00:00
|
|
|
Records.getAllDerivedDefinitions("RegisterOperand");
|
2024-09-18 22:27:26 -07:00
|
|
|
ArrayRef<const Record *> RegisterClasses =
|
2019-09-23 18:51:00 +00:00
|
|
|
Records.getAllDerivedDefinitions("RegisterClass");
|
2013-11-17 21:24:41 +00:00
|
|
|
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_OPERAND_TYPES_ENUM\n";
|
2013-11-17 21:24:41 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_OPERAND_TYPES_ENUM\n";
|
2015-03-13 01:10:08 +00:00
|
|
|
OS << "namespace llvm {\n";
|
2013-11-17 21:24:41 +00:00
|
|
|
OS << "namespace " << Namespace << " {\n";
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "namespace OpTypes {\n";
|
2013-11-17 21:24:41 +00:00
|
|
|
OS << "enum OperandType {\n";
|
|
|
|
|
2014-04-18 02:09:07 +00:00
|
|
|
unsigned EnumVal = 0;
|
2024-09-18 22:27:26 -07:00
|
|
|
for (ArrayRef<const Record *> RecordsToAdd :
|
|
|
|
{Operands, RegisterOperands, RegisterClasses}) {
|
|
|
|
for (const Record *Op : RecordsToAdd) {
|
2019-09-23 18:51:00 +00:00
|
|
|
if (!Op->isAnonymous())
|
|
|
|
OS << " " << Op->getName() << " = " << EnumVal << ",\n";
|
|
|
|
++EnumVal;
|
|
|
|
}
|
2013-11-17 21:24:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
OS << " OPERAND_TYPE_LIST_END"
|
|
|
|
<< "\n};\n";
|
2015-09-10 16:49:58 +00:00
|
|
|
OS << "} // end namespace OpTypes\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_OPERAND_TYPES_ENUM\n\n";
|
2019-07-16 22:10:16 +00:00
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_OPERAND_TYPE\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_OPERAND_TYPE\n";
|
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
|
|
|
OS << "LLVM_READONLY\n";
|
2019-09-23 18:51:00 +00:00
|
|
|
OS << "static int getOperandType(uint16_t Opcode, uint16_t OpIdx) {\n";
|
2022-06-20 12:58:31 -07:00
|
|
|
auto getInstrName = [&](int I) -> StringRef {
|
|
|
|
return NumberedInstructions[I]->TheDef->getName();
|
|
|
|
};
|
2020-12-11 16:19:52 -05:00
|
|
|
// TODO: Factor out duplicate operand lists to compress the tables.
|
2019-07-16 22:10:16 +00:00
|
|
|
if (!NumberedInstructions.empty()) {
|
2019-07-16 22:39:18 +00:00
|
|
|
std::vector<int> OperandOffsets;
|
2024-09-09 14:33:21 -07:00
|
|
|
std::vector<const Record *> OperandRecords;
|
2019-07-16 22:39:18 +00:00
|
|
|
int CurrentOffset = 0;
|
2019-07-16 22:10:16 +00:00
|
|
|
for (const CodeGenInstruction *Inst : NumberedInstructions) {
|
2019-07-16 22:39:18 +00:00
|
|
|
OperandOffsets.push_back(CurrentOffset);
|
2019-07-16 22:10:16 +00:00
|
|
|
for (const auto &Op : Inst->Operands) {
|
|
|
|
const DagInit *MIOI = Op.MIOperandInfo;
|
2022-06-29 00:59:01 -07:00
|
|
|
if (!ExpandMIOperandInfo || !MIOI || MIOI->getNumArgs() == 0) {
|
2019-07-16 22:10:16 +00:00
|
|
|
// Single, anonymous, operand.
|
2019-07-16 22:39:18 +00:00
|
|
|
OperandRecords.push_back(Op.Rec);
|
|
|
|
++CurrentOffset;
|
2019-07-16 22:10:16 +00:00
|
|
|
} else {
|
2021-01-09 09:24:59 -08:00
|
|
|
for (Init *Arg : MIOI->getArgs()) {
|
2019-07-16 22:39:18 +00:00
|
|
|
OperandRecords.push_back(cast<DefInit>(Arg)->getDef());
|
|
|
|
++CurrentOffset;
|
2019-07-16 22:10:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-07-16 22:39:18 +00:00
|
|
|
|
2020-12-11 16:19:52 -05:00
|
|
|
// Emit the table of offsets (indexes) into the operand type table.
|
|
|
|
// Size the unsigned integer offset to save space.
|
|
|
|
assert(OperandRecords.size() <= UINT32_MAX &&
|
|
|
|
"Too many operands for offset table");
|
2023-02-22 03:36:36 -05:00
|
|
|
OS << " static const " << getMinimalTypeForRange(OperandRecords.size());
|
2020-12-11 16:19:52 -05:00
|
|
|
OS << " Offsets[] = {\n";
|
2022-06-20 12:58:31 -07:00
|
|
|
for (int I = 0, E = OperandOffsets.size(); I != E; ++I) {
|
|
|
|
OS << " /* " << getInstrName(I) << " */\n";
|
2019-07-16 22:39:18 +00:00
|
|
|
OS << " " << OperandOffsets[I] << ",\n";
|
2022-06-20 12:58:31 -07:00
|
|
|
}
|
2019-07-16 22:10:16 +00:00
|
|
|
OS << " };\n";
|
2019-07-16 22:39:18 +00:00
|
|
|
|
|
|
|
// Add an entry for the end so that we don't need to special case it below.
|
|
|
|
OperandOffsets.push_back(OperandRecords.size());
|
2020-12-11 16:19:52 -05:00
|
|
|
|
2019-07-16 22:39:18 +00:00
|
|
|
// Emit the actual operand types in a flat table.
|
2020-12-11 16:19:52 -05:00
|
|
|
// Size the signed integer operand type to save space.
|
|
|
|
assert(EnumVal <= INT16_MAX &&
|
|
|
|
"Too many operand types for operand types table");
|
2022-06-20 12:58:31 -07:00
|
|
|
OS << "\n using namespace OpTypes;\n";
|
2023-02-22 03:36:36 -05:00
|
|
|
OS << " static";
|
|
|
|
OS << ((EnumVal <= INT8_MAX) ? " const int8_t" : " const int16_t");
|
2020-12-11 16:19:52 -05:00
|
|
|
OS << " OpcodeOperandTypes[] = {\n ";
|
2022-06-20 12:58:31 -07:00
|
|
|
for (int I = 0, E = OperandRecords.size(), CurOffset = 0; I != E; ++I) {
|
2019-07-16 22:39:18 +00:00
|
|
|
// We print each Opcode's operands in its own row.
|
|
|
|
if (I == OperandOffsets[CurOffset]) {
|
2022-06-20 12:58:31 -07:00
|
|
|
OS << "\n /* " << getInstrName(CurOffset) << " */\n ";
|
2019-07-16 22:39:18 +00:00
|
|
|
while (OperandOffsets[++CurOffset] == I)
|
2022-06-20 12:58:31 -07:00
|
|
|
OS << "/* " << getInstrName(CurOffset) << " */\n ";
|
2019-07-16 22:39:18 +00:00
|
|
|
}
|
2024-09-09 14:33:21 -07:00
|
|
|
const Record *OpR = OperandRecords[I];
|
2019-09-23 18:51:00 +00:00
|
|
|
if ((OpR->isSubClassOf("Operand") ||
|
|
|
|
OpR->isSubClassOf("RegisterOperand") ||
|
|
|
|
OpR->isSubClassOf("RegisterClass")) &&
|
|
|
|
!OpR->isAnonymous())
|
2022-06-20 12:58:31 -07:00
|
|
|
OS << OpR->getName();
|
2019-07-16 22:39:18 +00:00
|
|
|
else
|
|
|
|
OS << -1;
|
|
|
|
OS << ", ";
|
|
|
|
}
|
|
|
|
OS << "\n };\n";
|
|
|
|
|
|
|
|
OS << " return OpcodeOperandTypes[Offsets[Opcode] + OpIdx];\n";
|
2019-07-16 22:10:16 +00:00
|
|
|
} else {
|
|
|
|
OS << " llvm_unreachable(\"No instructions defined\");\n";
|
|
|
|
}
|
|
|
|
OS << "}\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2019-09-23 18:51:00 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_OPERAND_TYPE\n\n";
|
2022-06-19 11:46:35 -07:00
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_MEM_OPERAND_SIZE\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_MEM_OPERAND_SIZE\n";
|
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
|
|
|
OS << "LLVM_READONLY\n";
|
|
|
|
OS << "static int getMemOperandSize(int OpType) {\n";
|
|
|
|
OS << " switch (OpType) {\n";
|
2023-09-27 12:41:54 -07:00
|
|
|
std::map<int, SmallVector<StringRef, 0>> SizeToOperandName;
|
2022-06-19 11:46:35 -07:00
|
|
|
for (const Record *Op : Operands) {
|
|
|
|
if (!Op->isSubClassOf("X86MemOperand"))
|
|
|
|
continue;
|
|
|
|
if (int Size = Op->getValueAsInt("Size"))
|
|
|
|
SizeToOperandName[Size].push_back(Op->getName());
|
|
|
|
}
|
|
|
|
OS << " default: return 0;\n";
|
2023-09-27 12:41:54 -07:00
|
|
|
for (const auto &KV : SizeToOperandName) {
|
2022-06-19 11:46:35 -07:00
|
|
|
for (const StringRef &OperandName : KV.second)
|
|
|
|
OS << " case OpTypes::" << OperandName << ":\n";
|
|
|
|
OS << " return " << KV.first << ";\n\n";
|
|
|
|
}
|
|
|
|
OS << " }\n}\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
|
|
|
OS << "#endif // GET_INSTRINFO_MEM_OPERAND_SIZE\n\n";
|
2013-11-17 21:24:41 +00:00
|
|
|
}
|
|
|
|
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
void InstrInfoEmitter::emitLogicalOperandSizeMappings(
|
|
|
|
raw_ostream &OS, StringRef Namespace,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions) {
|
|
|
|
std::map<std::vector<unsigned>, unsigned> LogicalOpSizeMap;
|
|
|
|
|
|
|
|
std::map<unsigned, std::vector<std::string>> InstMap;
|
|
|
|
|
|
|
|
size_t LogicalOpListSize = 0U;
|
|
|
|
std::vector<unsigned> LogicalOpList;
|
|
|
|
for (const auto *Inst : NumberedInstructions) {
|
|
|
|
if (!Inst->TheDef->getValueAsBit("UseLogicalOperandMappings"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LogicalOpList.clear();
|
|
|
|
llvm::transform(Inst->Operands, std::back_inserter(LogicalOpList),
|
|
|
|
[](const CGIOperandList::OperandInfo &Op) -> unsigned {
|
|
|
|
auto *MIOI = Op.MIOperandInfo;
|
|
|
|
if (!MIOI || MIOI->getNumArgs() == 0)
|
|
|
|
return 1;
|
|
|
|
return MIOI->getNumArgs();
|
|
|
|
});
|
|
|
|
LogicalOpListSize = std::max(LogicalOpList.size(), LogicalOpListSize);
|
|
|
|
|
|
|
|
auto I =
|
|
|
|
LogicalOpSizeMap.insert({LogicalOpList, LogicalOpSizeMap.size()}).first;
|
|
|
|
InstMap[I->second].push_back(
|
|
|
|
(Namespace + "::" + Inst->TheDef->getName()).str());
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_LOGICAL_OPERAND_SIZE_MAP\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_LOGICAL_OPERAND_SIZE_MAP\n";
|
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
|
|
|
OS << "LLVM_READONLY static unsigned\n";
|
|
|
|
OS << "getLogicalOperandSize(uint16_t Opcode, uint16_t LogicalOpIdx) {\n";
|
|
|
|
if (!InstMap.empty()) {
|
|
|
|
std::vector<const std::vector<unsigned> *> LogicalOpSizeList(
|
|
|
|
LogicalOpSizeMap.size());
|
|
|
|
for (auto &P : LogicalOpSizeMap) {
|
|
|
|
LogicalOpSizeList[P.second] = &P.first;
|
|
|
|
}
|
|
|
|
OS << " static const unsigned SizeMap[][" << LogicalOpListSize
|
|
|
|
<< "] = {\n";
|
2021-05-06 18:36:52 +08:00
|
|
|
for (auto &R : LogicalOpSizeList) {
|
|
|
|
const auto &Row = *R;
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
OS << " {";
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < static_cast<int>(Row.size()); ++i) {
|
|
|
|
OS << Row[i] << ", ";
|
|
|
|
}
|
|
|
|
for (; i < static_cast<int>(LogicalOpListSize); ++i) {
|
|
|
|
OS << "0, ";
|
|
|
|
}
|
|
|
|
OS << "}, ";
|
|
|
|
OS << "\n";
|
|
|
|
}
|
|
|
|
OS << " };\n";
|
|
|
|
|
|
|
|
OS << " switch (Opcode) {\n";
|
|
|
|
OS << " default: return LogicalOpIdx;\n";
|
|
|
|
for (auto &P : InstMap) {
|
|
|
|
auto OpMapIdx = P.first;
|
|
|
|
const auto &Insts = P.second;
|
|
|
|
for (const auto &Inst : Insts) {
|
|
|
|
OS << " case " << Inst << ":\n";
|
|
|
|
}
|
|
|
|
OS << " return SizeMap[" << OpMapIdx << "][LogicalOpIdx];\n";
|
|
|
|
}
|
|
|
|
OS << " }\n";
|
|
|
|
} else {
|
|
|
|
OS << " return LogicalOpIdx;\n";
|
|
|
|
}
|
|
|
|
OS << "}\n";
|
|
|
|
|
|
|
|
OS << "LLVM_READONLY static inline unsigned\n";
|
|
|
|
OS << "getLogicalOperandIdx(uint16_t Opcode, uint16_t LogicalOpIdx) {\n";
|
|
|
|
OS << " auto S = 0U;\n";
|
|
|
|
OS << " for (auto i = 0U; i < LogicalOpIdx; ++i)\n";
|
|
|
|
OS << " S += getLogicalOperandSize(Opcode, i);\n";
|
|
|
|
OS << " return S;\n";
|
|
|
|
OS << "}\n";
|
|
|
|
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
|
|
|
OS << "#endif // GET_INSTRINFO_LOGICAL_OPERAND_SIZE_MAP\n\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void InstrInfoEmitter::emitLogicalOperandTypeMappings(
|
|
|
|
raw_ostream &OS, StringRef Namespace,
|
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions) {
|
|
|
|
std::map<std::vector<std::string>, unsigned> LogicalOpTypeMap;
|
|
|
|
|
|
|
|
std::map<unsigned, std::vector<std::string>> InstMap;
|
|
|
|
|
|
|
|
size_t OpTypeListSize = 0U;
|
|
|
|
std::vector<std::string> LogicalOpTypeList;
|
|
|
|
for (const auto *Inst : NumberedInstructions) {
|
|
|
|
if (!Inst->TheDef->getValueAsBit("UseLogicalOperandMappings"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LogicalOpTypeList.clear();
|
|
|
|
for (const auto &Op : Inst->Operands) {
|
|
|
|
auto *OpR = Op.Rec;
|
|
|
|
if ((OpR->isSubClassOf("Operand") ||
|
|
|
|
OpR->isSubClassOf("RegisterOperand") ||
|
|
|
|
OpR->isSubClassOf("RegisterClass")) &&
|
|
|
|
!OpR->isAnonymous()) {
|
|
|
|
LogicalOpTypeList.push_back(
|
|
|
|
(Namespace + "::OpTypes::" + Op.Rec->getName()).str());
|
|
|
|
} else {
|
|
|
|
LogicalOpTypeList.push_back("-1");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OpTypeListSize = std::max(LogicalOpTypeList.size(), OpTypeListSize);
|
|
|
|
|
|
|
|
auto I =
|
|
|
|
LogicalOpTypeMap.insert({LogicalOpTypeList, LogicalOpTypeMap.size()})
|
|
|
|
.first;
|
|
|
|
InstMap[I->second].push_back(
|
|
|
|
(Namespace + "::" + Inst->TheDef->getName()).str());
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_LOGICAL_OPERAND_TYPE_MAP\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_LOGICAL_OPERAND_TYPE_MAP\n";
|
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
|
|
|
OS << "LLVM_READONLY static int\n";
|
|
|
|
OS << "getLogicalOperandType(uint16_t Opcode, uint16_t LogicalOpIdx) {\n";
|
|
|
|
if (!InstMap.empty()) {
|
|
|
|
std::vector<const std::vector<std::string> *> LogicalOpTypeList(
|
|
|
|
LogicalOpTypeMap.size());
|
|
|
|
for (auto &P : LogicalOpTypeMap) {
|
|
|
|
LogicalOpTypeList[P.second] = &P.first;
|
|
|
|
}
|
|
|
|
OS << " static const int TypeMap[][" << OpTypeListSize << "] = {\n";
|
|
|
|
for (int r = 0, rs = LogicalOpTypeList.size(); r < rs; ++r) {
|
|
|
|
const auto &Row = *LogicalOpTypeList[r];
|
|
|
|
OS << " {";
|
|
|
|
int i, s = Row.size();
|
|
|
|
for (i = 0; i < s; ++i) {
|
|
|
|
if (i > 0)
|
|
|
|
OS << ", ";
|
|
|
|
OS << Row[i];
|
|
|
|
}
|
|
|
|
for (; i < static_cast<int>(OpTypeListSize); ++i) {
|
|
|
|
if (i > 0)
|
|
|
|
OS << ", ";
|
|
|
|
OS << "-1";
|
|
|
|
}
|
|
|
|
OS << "}";
|
|
|
|
if (r != rs - 1)
|
|
|
|
OS << ",";
|
|
|
|
OS << "\n";
|
|
|
|
}
|
|
|
|
OS << " };\n";
|
|
|
|
|
|
|
|
OS << " switch (Opcode) {\n";
|
|
|
|
OS << " default: return -1;\n";
|
|
|
|
for (auto &P : InstMap) {
|
|
|
|
auto OpMapIdx = P.first;
|
|
|
|
const auto &Insts = P.second;
|
|
|
|
for (const auto &Inst : Insts) {
|
|
|
|
OS << " case " << Inst << ":\n";
|
|
|
|
}
|
|
|
|
OS << " return TypeMap[" << OpMapIdx << "][LogicalOpIdx];\n";
|
|
|
|
}
|
|
|
|
OS << " }\n";
|
|
|
|
} else {
|
|
|
|
OS << " return -1;\n";
|
|
|
|
}
|
|
|
|
OS << "}\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
|
|
|
OS << "#endif // GET_INSTRINFO_LOGICAL_OPERAND_TYPE_MAP\n\n";
|
|
|
|
}
|
|
|
|
|
2018-08-14 18:36:54 +00:00
|
|
|
void InstrInfoEmitter::emitMCIIHelperMethods(raw_ostream &OS,
|
|
|
|
StringRef TargetName) {
|
2024-09-18 04:45:49 -07:00
|
|
|
ArrayRef<const Record *> TIIPredicates =
|
|
|
|
Records.getAllDerivedDefinitions("TIIPredicate");
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_MC_HELPER_DECLS\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_MC_HELPER_DECLS\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-08-13 15:13:35 +00:00
|
|
|
OS << "namespace llvm {\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
OS << "class MCInst;\n";
|
|
|
|
OS << "class FeatureBitset;\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-08-13 15:13:35 +00:00
|
|
|
OS << "namespace " << TargetName << "_MC {\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
|
|
|
for (const Record *Rec : TIIPredicates) {
|
2018-08-13 15:13:35 +00:00
|
|
|
OS << "bool " << Rec->getValueAsString("FunctionName")
|
2018-05-25 16:02:43 +00:00
|
|
|
<< "(const MCInst &MI);\n";
|
|
|
|
}
|
|
|
|
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
OS << "void verifyInstructionPredicates(unsigned Opcode, const FeatureBitset "
|
|
|
|
"&Features);\n";
|
|
|
|
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "\n} // end namespace " << TargetName << "_MC\n";
|
|
|
|
OS << "} // end namespace llvm\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_MC_HELPER_DECLS\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_MC_HELPERS\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_MC_HELPERS\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-08-13 15:13:35 +00:00
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << TargetName << "_MC {\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
2018-08-14 18:36:54 +00:00
|
|
|
PredicateExpander PE(TargetName);
|
2018-05-25 16:02:43 +00:00
|
|
|
PE.setExpandForMC(true);
|
2018-08-13 15:13:35 +00:00
|
|
|
|
2018-05-25 16:02:43 +00:00
|
|
|
for (const Record *Rec : TIIPredicates) {
|
2018-08-13 15:13:35 +00:00
|
|
|
OS << "bool " << Rec->getValueAsString("FunctionName");
|
|
|
|
OS << "(const MCInst &MI) {\n";
|
|
|
|
|
|
|
|
OS.indent(PE.getIndentLevel() * 2);
|
|
|
|
PE.expandStatement(OS, Rec->getValueAsDef("Body"));
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << "\n}\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
}
|
|
|
|
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "} // end namespace " << TargetName << "_MC\n";
|
|
|
|
OS << "} // end namespace llvm\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
OS << "#endif // GET_GENISTRINFO_MC_HELPERS\n\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
static std::string
|
2024-09-11 08:53:21 -07:00
|
|
|
getNameForFeatureBitset(ArrayRef<const Record *> FeatureBitset) {
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
std::string Name = "CEFBS";
|
2024-09-11 08:53:21 -07:00
|
|
|
for (const Record *Feature : FeatureBitset)
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
Name += ("_" + Feature->getName()).str();
|
|
|
|
return Name;
|
|
|
|
}
|
|
|
|
|
|
|
|
void InstrInfoEmitter::emitFeatureVerifier(raw_ostream &OS,
|
|
|
|
const CodeGenTarget &Target) {
|
|
|
|
const auto &All = SubtargetFeatureInfo::getAll(Records);
|
2024-09-11 08:53:21 -07:00
|
|
|
SubtargetFeatureInfoMap SubtargetFeatures;
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
SubtargetFeatures.insert(All.begin(), All.end());
|
|
|
|
|
2023-08-02 15:41:46 +03:00
|
|
|
OS << "#if (defined(ENABLE_INSTR_PREDICATE_VERIFIER) && !defined(NDEBUG)) "
|
|
|
|
<< "||\\\n"
|
|
|
|
<< " defined(GET_AVAILABLE_OPCODE_CHECKER)\n"
|
2023-06-07 16:05:46 +03:00
|
|
|
<< "#define GET_COMPUTE_FEATURES\n"
|
|
|
|
<< "#endif\n";
|
|
|
|
OS << "#ifdef GET_COMPUTE_FEATURES\n"
|
|
|
|
<< "#undef GET_COMPUTE_FEATURES\n"
|
|
|
|
<< "namespace llvm {\n"
|
|
|
|
<< "namespace " << Target.getName() << "_MC {\n\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
|
|
|
|
// Emit the subtarget feature enumeration.
|
|
|
|
SubtargetFeatureInfo::emitSubtargetFeatureBitEnumeration(SubtargetFeatures,
|
|
|
|
OS);
|
|
|
|
// Emit the available features compute function.
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << "inline ";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
SubtargetFeatureInfo::emitComputeAssemblerAvailableFeatures(
|
|
|
|
Target.getName(), "", "computeAvailableFeatures", SubtargetFeatures, OS);
|
|
|
|
|
2024-09-11 08:53:21 -07:00
|
|
|
std::vector<std::vector<const Record *>> FeatureBitsets;
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
for (const CodeGenInstruction *Inst : Target.getInstructionsByEnumValue()) {
|
|
|
|
FeatureBitsets.emplace_back();
|
2024-09-11 08:53:21 -07:00
|
|
|
for (const Record *Predicate :
|
|
|
|
Inst->TheDef->getValueAsListOfDefs("Predicates")) {
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
const auto &I = SubtargetFeatures.find(Predicate);
|
|
|
|
if (I != SubtargetFeatures.end())
|
|
|
|
FeatureBitsets.back().push_back(I->second.TheDef);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-09-18 22:27:26 -07:00
|
|
|
llvm::sort(FeatureBitsets, [&](ArrayRef<const Record *> A,
|
|
|
|
ArrayRef<const Record *> B) {
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
if (A.size() < B.size())
|
|
|
|
return true;
|
|
|
|
if (A.size() > B.size())
|
|
|
|
return false;
|
|
|
|
for (auto Pair : zip(A, B)) {
|
|
|
|
if (std::get<0>(Pair)->getName() < std::get<1>(Pair)->getName())
|
|
|
|
return true;
|
|
|
|
if (std::get<0>(Pair)->getName() > std::get<1>(Pair)->getName())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
});
|
2024-06-02 11:52:12 -07:00
|
|
|
FeatureBitsets.erase(llvm::unique(FeatureBitsets), FeatureBitsets.end());
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << "inline FeatureBitset computeRequiredFeatures(unsigned Opcode) {\n"
|
|
|
|
<< " enum : " << getMinimalTypeForRange(FeatureBitsets.size()) << " {\n"
|
|
|
|
<< " CEFBS_None,\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
for (const auto &FeatureBitset : FeatureBitsets) {
|
|
|
|
if (FeatureBitset.empty())
|
|
|
|
continue;
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " " << getNameForFeatureBitset(FeatureBitset) << ",\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
}
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " };\n\n"
|
|
|
|
<< " static constexpr FeatureBitset FeatureBitsets[] = {\n"
|
|
|
|
<< " {}, // CEFBS_None\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
for (const auto &FeatureBitset : FeatureBitsets) {
|
|
|
|
if (FeatureBitset.empty())
|
|
|
|
continue;
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " {";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
for (const auto &Feature : FeatureBitset) {
|
|
|
|
const auto &I = SubtargetFeatures.find(Feature);
|
|
|
|
assert(I != SubtargetFeatures.end() && "Didn't import predicate?");
|
|
|
|
OS << I->second.getEnumBitName() << ", ";
|
|
|
|
}
|
|
|
|
OS << "},\n";
|
|
|
|
}
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " };\n"
|
2023-08-21 17:18:39 +02:00
|
|
|
<< " static constexpr " << getMinimalTypeForRange(FeatureBitsets.size())
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
<< " RequiredFeaturesRefs[] = {\n";
|
|
|
|
unsigned InstIdx = 0;
|
|
|
|
for (const CodeGenInstruction *Inst : Target.getInstructionsByEnumValue()) {
|
|
|
|
OS << " CEFBS";
|
|
|
|
unsigned NumPredicates = 0;
|
2024-09-11 08:53:21 -07:00
|
|
|
for (const Record *Predicate :
|
|
|
|
Inst->TheDef->getValueAsListOfDefs("Predicates")) {
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
const auto &I = SubtargetFeatures.find(Predicate);
|
|
|
|
if (I != SubtargetFeatures.end()) {
|
|
|
|
OS << '_' << I->second.TheDef->getName();
|
|
|
|
NumPredicates++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!NumPredicates)
|
|
|
|
OS << "_None";
|
|
|
|
OS << ", // " << Inst->TheDef->getName() << " = " << InstIdx << "\n";
|
|
|
|
InstIdx++;
|
|
|
|
}
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " };\n\n"
|
|
|
|
<< " assert(Opcode < " << InstIdx << ");\n"
|
|
|
|
<< " return FeatureBitsets[RequiredFeaturesRefs[Opcode]];\n"
|
|
|
|
<< "}\n\n";
|
|
|
|
|
|
|
|
OS << "} // end namespace " << Target.getName() << "_MC\n"
|
|
|
|
<< "} // end namespace llvm\n"
|
|
|
|
<< "#endif // GET_COMPUTE_FEATURES\n\n";
|
|
|
|
|
2023-08-02 15:41:46 +03:00
|
|
|
OS << "#ifdef GET_AVAILABLE_OPCODE_CHECKER\n"
|
|
|
|
<< "#undef GET_AVAILABLE_OPCODE_CHECKER\n"
|
|
|
|
<< "namespace llvm {\n"
|
|
|
|
<< "namespace " << Target.getName() << "_MC {\n";
|
|
|
|
OS << "bool isOpcodeAvailable("
|
|
|
|
<< "unsigned Opcode, const FeatureBitset &Features) {\n"
|
|
|
|
<< " FeatureBitset AvailableFeatures = "
|
|
|
|
<< "computeAvailableFeatures(Features);\n"
|
|
|
|
<< " FeatureBitset RequiredFeatures = "
|
|
|
|
<< "computeRequiredFeatures(Opcode);\n"
|
|
|
|
<< " FeatureBitset MissingFeatures =\n"
|
|
|
|
<< " (AvailableFeatures & RequiredFeatures) ^\n"
|
|
|
|
<< " RequiredFeatures;\n"
|
|
|
|
<< " return !MissingFeatures.any();\n"
|
|
|
|
<< "}\n";
|
|
|
|
OS << "} // end namespace " << Target.getName() << "_MC\n"
|
|
|
|
<< "} // end namespace llvm\n"
|
|
|
|
<< "#endif // GET_AVAILABLE_OPCODE_CHECKER\n\n";
|
|
|
|
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << "#ifdef ENABLE_INSTR_PREDICATE_VERIFIER\n"
|
|
|
|
<< "#undef ENABLE_INSTR_PREDICATE_VERIFIER\n"
|
|
|
|
<< "#include <sstream>\n\n";
|
|
|
|
|
|
|
|
OS << "namespace llvm {\n";
|
|
|
|
OS << "namespace " << Target.getName() << "_MC {\n\n";
|
|
|
|
|
|
|
|
// Emit the name table for error messages.
|
|
|
|
OS << "#ifndef NDEBUG\n";
|
|
|
|
SubtargetFeatureInfo::emitNameTable(SubtargetFeatures, OS);
|
|
|
|
OS << "#endif // NDEBUG\n\n";
|
|
|
|
|
|
|
|
// Emit the predicate verifier.
|
|
|
|
OS << "void verifyInstructionPredicates(\n"
|
|
|
|
<< " unsigned Opcode, const FeatureBitset &Features) {\n"
|
|
|
|
<< "#ifndef NDEBUG\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
OS << " FeatureBitset AvailableFeatures = "
|
|
|
|
"computeAvailableFeatures(Features);\n";
|
2023-06-07 16:05:46 +03:00
|
|
|
OS << " FeatureBitset RequiredFeatures = "
|
|
|
|
<< "computeRequiredFeatures(Opcode);\n";
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
OS << " FeatureBitset MissingFeatures =\n"
|
|
|
|
<< " (AvailableFeatures & RequiredFeatures) ^\n"
|
|
|
|
<< " RequiredFeatures;\n"
|
|
|
|
<< " if (MissingFeatures.any()) {\n"
|
|
|
|
<< " std::ostringstream Msg;\n"
|
|
|
|
<< " Msg << \"Attempting to emit \" << &" << Target.getName()
|
|
|
|
<< "InstrNameData[" << Target.getName() << "InstrNameIndices[Opcode]]\n"
|
|
|
|
<< " << \" instruction but the \";\n"
|
|
|
|
<< " for (unsigned i = 0, e = MissingFeatures.size(); i != e; ++i)\n"
|
|
|
|
<< " if (MissingFeatures.test(i))\n"
|
|
|
|
<< " Msg << SubtargetFeatureNames[i] << \" \";\n"
|
|
|
|
<< " Msg << \"predicate(s) are not met\";\n"
|
|
|
|
<< " report_fatal_error(Msg.str().c_str());\n"
|
|
|
|
<< " }\n"
|
|
|
|
<< "#endif // NDEBUG\n";
|
|
|
|
OS << "}\n";
|
|
|
|
OS << "} // end namespace " << Target.getName() << "_MC\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
|
|
|
OS << "#endif // ENABLE_INSTR_PREDICATE_VERIFIER\n\n";
|
2018-05-25 16:02:43 +00:00
|
|
|
}
|
|
|
|
|
2018-08-14 18:36:54 +00:00
|
|
|
void InstrInfoEmitter::emitTIIHelperMethods(raw_ostream &OS,
|
[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
2018-10-31 12:28:05 +00:00
|
|
|
StringRef TargetName,
|
|
|
|
bool ExpandDefinition) {
|
2024-09-11 08:53:21 -07:00
|
|
|
ArrayRef<const Record *> TIIPredicates =
|
|
|
|
Records.getAllDerivedDefinitions("TIIPredicate");
|
2018-05-25 15:55:37 +00:00
|
|
|
if (TIIPredicates.empty())
|
|
|
|
return;
|
|
|
|
|
2018-08-14 18:36:54 +00:00
|
|
|
PredicateExpander PE(TargetName);
|
2018-05-25 15:55:37 +00:00
|
|
|
PE.setExpandForMC(false);
|
|
|
|
|
|
|
|
for (const Record *Rec : TIIPredicates) {
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << (ExpandDefinition ? "" : "static ") << "bool ";
|
[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
2018-10-31 12:28:05 +00:00
|
|
|
if (ExpandDefinition)
|
|
|
|
OS << TargetName << "InstrInfo::";
|
|
|
|
OS << Rec->getValueAsString("FunctionName");
|
|
|
|
OS << "(const MachineInstr &MI)";
|
|
|
|
if (!ExpandDefinition) {
|
|
|
|
OS << ";\n";
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << " {\n";
|
2018-08-13 15:13:35 +00:00
|
|
|
OS.indent(PE.getIndentLevel() * 2);
|
|
|
|
PE.expandStatement(OS, Rec->getValueAsDef("Body"));
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << "\n}\n\n";
|
2018-05-25 15:55:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-06 01:20:13 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Main Output.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2003-10-05 19:27:59 +00:00
|
|
|
|
|
|
|
// run - Emit the main instruction description records for the target...
|
2009-07-03 00:10:29 +00:00
|
|
|
void InstrInfoEmitter::run(raw_ostream &OS) {
|
2016-02-11 07:39:27 +00:00
|
|
|
emitSourceFileHeader("Target Instruction Enum Values and Descriptors", OS);
|
2011-06-28 20:07:07 +00:00
|
|
|
emitEnums(OS);
|
|
|
|
|
2024-09-18 22:27:26 -07:00
|
|
|
const CodeGenTarget &Target = CDP.getTargetInfo();
|
2020-01-28 20:23:46 +01:00
|
|
|
const std::string &TargetName = std::string(Target.getName());
|
2024-09-18 22:27:26 -07:00
|
|
|
const Record *InstrInfo = Target.getInstructionSet();
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
// Collect all of the operand info records.
|
|
|
|
Records.startTimer("Collect operand info");
|
|
|
|
OperandInfoListTy OperandInfoList;
|
|
|
|
OperandInfoMapTy OperandInfoMap;
|
|
|
|
unsigned OperandInfoSize =
|
|
|
|
CollectOperandInfo(OperandInfoList, OperandInfoMap);
|
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
// Collect all of the instruction's implicit uses and defs.
|
|
|
|
Records.startTimer("Collect uses/defs");
|
2024-09-18 22:27:26 -07:00
|
|
|
std::map<std::vector<const Record *>, unsigned> EmittedLists;
|
|
|
|
std::vector<std::vector<const Record *>> ImplicitLists;
|
2023-01-12 07:38:13 +00:00
|
|
|
unsigned ImplicitListSize = 0;
|
2016-01-17 20:38:18 +00:00
|
|
|
for (const CodeGenInstruction *II : Target.getInstructionsByEnumValue()) {
|
2024-09-18 22:27:26 -07:00
|
|
|
std::vector<const Record *> ImplicitOps = II->ImplicitUses;
|
2023-01-11 13:45:46 +00:00
|
|
|
llvm::append_range(ImplicitOps, II->ImplicitDefs);
|
2023-01-12 07:38:13 +00:00
|
|
|
if (EmittedLists.insert({ImplicitOps, ImplicitListSize}).second) {
|
|
|
|
ImplicitLists.push_back(ImplicitOps);
|
|
|
|
ImplicitListSize += ImplicitOps.size();
|
2005-08-18 21:36:47 +00:00
|
|
|
}
|
2003-10-05 19:27:59 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions =
|
|
|
|
Target.getInstructionsByEnumValue();
|
|
|
|
OS << "#if defined(GET_INSTRINFO_MC_DESC) || "
|
|
|
|
"defined(GET_INSTRINFO_CTOR_DTOR)\n";
|
|
|
|
OS << "namespace llvm {\n\n";
|
|
|
|
|
|
|
|
OS << "struct " << TargetName << "InstrTable {\n";
|
|
|
|
OS << " MCInstrDesc Insts[" << NumberedInstructions.size() << "];\n";
|
2023-01-12 21:02:23 +00:00
|
|
|
OS << " static_assert(alignof(MCInstrDesc) >= alignof(MCOperandInfo), "
|
|
|
|
"\"Unwanted padding between Insts and OperandInfo\");\n";
|
|
|
|
OS << " MCOperandInfo OperandInfo[" << OperandInfoSize << "];\n";
|
|
|
|
OS << " static_assert(alignof(MCOperandInfo) >= alignof(MCPhysReg), "
|
|
|
|
"\"Unwanted padding between OperandInfo and ImplicitOps\");\n";
|
2023-01-12 07:38:13 +00:00
|
|
|
OS << " MCPhysReg ImplicitOps[" << std::max(ImplicitListSize, 1U) << "];\n";
|
|
|
|
OS << "};\n\n";
|
|
|
|
|
|
|
|
OS << "} // end namespace llvm\n";
|
|
|
|
OS << "#endif // defined(GET_INSTRINFO_MC_DESC) || "
|
|
|
|
"defined(GET_INSTRINFO_CTOR_DTOR)\n\n";
|
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_MC_DESC\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_MC_DESC\n";
|
|
|
|
OS << "namespace llvm {\n\n";
|
2011-06-27 21:06:21 +00:00
|
|
|
|
2023-01-11 15:18:42 +00:00
|
|
|
// Emit all of the MCInstrDesc records in reverse ENUM ordering.
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit InstrDesc records");
|
2023-01-12 21:02:23 +00:00
|
|
|
OS << "static_assert(sizeof(MCOperandInfo) % sizeof(MCPhysReg) == 0);\n";
|
|
|
|
OS << "static constexpr unsigned " << TargetName << "ImpOpBase = sizeof "
|
|
|
|
<< TargetName << "InstrTable::OperandInfo / (sizeof(MCPhysReg));\n\n";
|
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
OS << "extern const " << TargetName << "InstrTable " << TargetName
|
|
|
|
<< "Descs = {\n {\n";
|
2012-04-01 18:14:14 +00:00
|
|
|
SequenceToOffsetTable<std::string> InstrNames;
|
2023-01-11 15:18:42 +00:00
|
|
|
unsigned Num = NumberedInstructions.size();
|
|
|
|
for (const CodeGenInstruction *Inst : reverse(NumberedInstructions)) {
|
2014-04-18 02:09:07 +00:00
|
|
|
// Keep a list of the instruction names.
|
2020-01-28 20:23:46 +01:00
|
|
|
InstrNames.add(std::string(Inst->TheDef->getName()));
|
2014-04-18 02:09:07 +00:00
|
|
|
// Emit the record into the table.
|
2023-01-12 21:02:23 +00:00
|
|
|
emitRecord(*Inst, --Num, InstrInfo, EmittedLists, OperandInfoMap, OS);
|
2012-04-01 18:14:14 +00:00
|
|
|
}
|
2023-01-12 07:38:13 +00:00
|
|
|
|
|
|
|
OS << " }, {\n";
|
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
// Emit all of the operand info records.
|
|
|
|
Records.startTimer("Emit operand info");
|
|
|
|
EmitOperandInfo(OS, OperandInfoList);
|
|
|
|
|
|
|
|
OS << " }, {\n";
|
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
// Emit all of the instruction's implicit uses and defs.
|
|
|
|
Records.startTimer("Emit uses/defs");
|
|
|
|
for (auto &List : ImplicitLists) {
|
|
|
|
OS << " /* " << EmittedLists[List] << " */";
|
|
|
|
for (auto &Reg : List)
|
|
|
|
OS << ' ' << getQualifiedName(Reg) << ',';
|
|
|
|
OS << '\n';
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << " }\n};\n\n";
|
2012-04-01 18:14:14 +00:00
|
|
|
|
2014-04-18 02:09:07 +00:00
|
|
|
// Emit the array of instruction names.
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit instruction names");
|
2012-04-01 18:14:14 +00:00
|
|
|
InstrNames.layout();
|
[tablegen] Emit string literals instead of char arrays
This changes the generated (Instr|Asm|Reg|Regclass)Name tables from this
form:
extern const char HexagonInstrNameData[] = {
/* 0 */ 'G', '_', 'F', 'L', 'O', 'G', '1', '0', 0,
/* 9 */ 'E', 'N', 'D', 'L', 'O', 'O', 'P', '0', 0,
/* 18 */ 'V', '6', '_', 'v', 'd', 'd', '0', 0,
/* 26 */ 'P', 'S', '_', 'v', 'd', 'd', '0', 0,
[...]
};
...to this:
extern const char HexagonInstrNameData[] = {
/* 0 */ "G_FLOG10\0"
/* 9 */ "ENDLOOP0\0"
/* 18 */ "V6_vdd0\0"
/* 26 */ "PS_vdd0\0"
[...]
};
This should make debugging and exploration a lot easier for mortals,
while providing a significant compile-time reduction for common compilers.
To avoid issues with low implementation limits, this is disabled by
default for visual studio.
To force output one way or the other, pass
`--long-string-literals=<bool>` to `tablegen`
Reviewers: mstorsjo, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D73044
A variation of this patch was originally committed in ce23515f5ab011 and
then reverted in e464b31c due to build failures.
2020-01-15 14:14:01 +00:00
|
|
|
InstrNames.emitStringLiteralDef(OS, Twine("extern const char ") + TargetName +
|
|
|
|
"InstrNameData[]");
|
2012-04-01 18:14:14 +00:00
|
|
|
|
|
|
|
OS << "extern const unsigned " << TargetName << "InstrNameIndices[] = {";
|
2014-04-18 02:09:07 +00:00
|
|
|
Num = 0;
|
|
|
|
for (const CodeGenInstruction *Inst : NumberedInstructions) {
|
|
|
|
// Newline every eight entries.
|
|
|
|
if (Num % 8 == 0)
|
2012-02-10 13:18:44 +00:00
|
|
|
OS << "\n ";
|
2020-01-28 20:23:46 +01:00
|
|
|
OS << InstrNames.get(std::string(Inst->TheDef->getName())) << "U, ";
|
2014-04-18 02:09:07 +00:00
|
|
|
++Num;
|
2012-02-10 13:18:44 +00:00
|
|
|
}
|
|
|
|
OS << "\n};\n\n";
|
|
|
|
|
2020-03-29 21:09:07 +02:00
|
|
|
bool HasDeprecationFeatures =
|
|
|
|
llvm::any_of(NumberedInstructions, [](const CodeGenInstruction *Inst) {
|
|
|
|
return !Inst->HasComplexDeprecationPredicate &&
|
|
|
|
!Inst->DeprecatedReason.empty();
|
|
|
|
});
|
|
|
|
if (HasDeprecationFeatures) {
|
|
|
|
OS << "extern const uint8_t " << TargetName
|
|
|
|
<< "InstrDeprecationFeatures[] = {";
|
|
|
|
Num = 0;
|
|
|
|
for (const CodeGenInstruction *Inst : NumberedInstructions) {
|
|
|
|
if (Num % 8 == 0)
|
|
|
|
OS << "\n ";
|
|
|
|
if (!Inst->HasComplexDeprecationPredicate &&
|
|
|
|
!Inst->DeprecatedReason.empty())
|
|
|
|
OS << Target.getInstNamespace() << "::" << Inst->DeprecatedReason
|
|
|
|
<< ", ";
|
|
|
|
else
|
|
|
|
OS << "uint8_t(-1), ";
|
|
|
|
++Num;
|
|
|
|
}
|
|
|
|
OS << "\n};\n\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
bool HasComplexDeprecationInfos =
|
|
|
|
llvm::any_of(NumberedInstructions, [](const CodeGenInstruction *Inst) {
|
|
|
|
return Inst->HasComplexDeprecationPredicate;
|
|
|
|
});
|
|
|
|
if (HasComplexDeprecationInfos) {
|
|
|
|
OS << "extern const MCInstrInfo::ComplexDeprecationPredicate " << TargetName
|
|
|
|
<< "InstrComplexDeprecationInfos[] = {";
|
|
|
|
Num = 0;
|
|
|
|
for (const CodeGenInstruction *Inst : NumberedInstructions) {
|
|
|
|
if (Num % 8 == 0)
|
|
|
|
OS << "\n ";
|
|
|
|
if (Inst->HasComplexDeprecationPredicate)
|
|
|
|
// Emit a function pointer to the complex predicate method.
|
|
|
|
OS << "&get" << Inst->DeprecatedReason << "DeprecationInfo, ";
|
|
|
|
else
|
|
|
|
OS << "nullptr, ";
|
|
|
|
++Num;
|
|
|
|
}
|
|
|
|
OS << "\n};\n\n";
|
|
|
|
}
|
|
|
|
|
2011-06-28 20:29:03 +00:00
|
|
|
// MCInstrInfo initialization routine.
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit initialization routine");
|
2011-06-28 20:29:03 +00:00
|
|
|
OS << "static inline void Init" << TargetName
|
|
|
|
<< "MCInstrInfo(MCInstrInfo *II) {\n";
|
2023-01-12 07:38:13 +00:00
|
|
|
OS << " II->InitMCInstrInfo(" << TargetName << "Descs.Insts, " << TargetName
|
2020-03-29 21:09:07 +02:00
|
|
|
<< "InstrNameIndices, " << TargetName << "InstrNameData, ";
|
|
|
|
if (HasDeprecationFeatures)
|
|
|
|
OS << TargetName << "InstrDeprecationFeatures, ";
|
|
|
|
else
|
|
|
|
OS << "nullptr, ";
|
|
|
|
if (HasComplexDeprecationInfos)
|
|
|
|
OS << TargetName << "InstrComplexDeprecationInfos, ";
|
|
|
|
else
|
|
|
|
OS << "nullptr, ";
|
|
|
|
OS << NumberedInstructions.size() << ");\n}\n\n";
|
2011-06-28 20:29:03 +00:00
|
|
|
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "} // end namespace llvm\n";
|
2011-06-28 20:07:07 +00:00
|
|
|
|
|
|
|
OS << "#endif // GET_INSTRINFO_MC_DESC\n\n";
|
2011-07-01 17:57:27 +00:00
|
|
|
|
|
|
|
// Create a TargetInstrInfo subclass to hide the MC layer initialization.
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_HEADER\n";
|
2011-07-01 17:57:27 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_HEADER\n";
|
|
|
|
|
|
|
|
std::string ClassName = TargetName + "GenInstrInfo";
|
2011-07-01 20:45:01 +00:00
|
|
|
OS << "namespace llvm {\n";
|
2012-11-28 02:35:17 +00:00
|
|
|
OS << "struct " << ClassName << " : public TargetInstrInfo {\n"
|
2015-03-13 01:26:39 +00:00
|
|
|
<< " explicit " << ClassName
|
2022-10-04 16:30:05 +05:30
|
|
|
<< "(unsigned CFSetupOpcode = ~0u, unsigned CFDestroyOpcode = ~0u, "
|
|
|
|
"unsigned CatchRetOpcode = ~0u, unsigned ReturnOpcode = ~0u);\n"
|
2018-05-25 15:55:37 +00:00
|
|
|
<< " ~" << ClassName << "() override = default;\n";
|
|
|
|
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "\n};\n} // end namespace llvm\n";
|
2011-07-01 17:57:27 +00:00
|
|
|
|
|
|
|
OS << "#endif // GET_INSTRINFO_HEADER\n\n";
|
|
|
|
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_HELPER_DECLS\n";
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_HELPER_DECLS\n\n";
|
2022-01-08 11:56:38 -08:00
|
|
|
emitTIIHelperMethods(OS, TargetName, /* ExpandDefinition = */ false);
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << "\n";
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_HELPER_DECLS\n\n";
|
[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
2018-10-31 12:28:05 +00:00
|
|
|
|
2018-11-27 20:58:27 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_HELPERS\n";
|
2018-12-04 01:43:22 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_HELPERS\n\n";
|
2022-01-08 11:56:38 -08:00
|
|
|
emitTIIHelperMethods(OS, TargetName, /* ExpandDefinition = */ true);
|
2018-12-04 01:43:19 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_HELPERS\n\n";
|
[tblgen][PredicateExpander] Add the ability to describe more complex constraints on instruction operands.
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
2018-10-31 12:28:05 +00:00
|
|
|
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_CTOR_DTOR\n";
|
2013-11-19 00:57:56 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_CTOR_DTOR\n";
|
2011-07-01 17:57:27 +00:00
|
|
|
|
2011-07-01 20:45:01 +00:00
|
|
|
OS << "namespace llvm {\n";
|
2023-01-12 07:38:13 +00:00
|
|
|
OS << "extern const " << TargetName << "InstrTable " << TargetName
|
|
|
|
<< "Descs;\n";
|
2012-03-15 18:05:57 +00:00
|
|
|
OS << "extern const unsigned " << TargetName << "InstrNameIndices[];\n";
|
2012-04-01 18:14:14 +00:00
|
|
|
OS << "extern const char " << TargetName << "InstrNameData[];\n";
|
2020-03-29 21:09:07 +02:00
|
|
|
if (HasDeprecationFeatures)
|
|
|
|
OS << "extern const uint8_t " << TargetName
|
|
|
|
<< "InstrDeprecationFeatures[];\n";
|
|
|
|
if (HasComplexDeprecationInfos)
|
|
|
|
OS << "extern const MCInstrInfo::ComplexDeprecationPredicate " << TargetName
|
|
|
|
<< "InstrComplexDeprecationInfos[];\n";
|
2015-03-13 01:26:39 +00:00
|
|
|
OS << ClassName << "::" << ClassName
|
2022-10-04 16:30:05 +05:30
|
|
|
<< "(unsigned CFSetupOpcode, unsigned CFDestroyOpcode, unsigned "
|
|
|
|
"CatchRetOpcode, unsigned ReturnOpcode)\n"
|
2020-03-29 21:09:07 +02:00
|
|
|
<< " : TargetInstrInfo(CFSetupOpcode, CFDestroyOpcode, CatchRetOpcode, "
|
|
|
|
"ReturnOpcode) {\n"
|
2023-01-12 07:38:13 +00:00
|
|
|
<< " InitMCInstrInfo(" << TargetName << "Descs.Insts, " << TargetName
|
2020-03-29 21:09:07 +02:00
|
|
|
<< "InstrNameIndices, " << TargetName << "InstrNameData, ";
|
|
|
|
if (HasDeprecationFeatures)
|
|
|
|
OS << TargetName << "InstrDeprecationFeatures, ";
|
|
|
|
else
|
|
|
|
OS << "nullptr, ";
|
|
|
|
if (HasComplexDeprecationInfos)
|
|
|
|
OS << TargetName << "InstrComplexDeprecationInfos, ";
|
|
|
|
else
|
|
|
|
OS << "nullptr, ";
|
|
|
|
OS << NumberedInstructions.size() << ");\n}\n";
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "} // end namespace llvm\n";
|
2011-07-01 17:57:27 +00:00
|
|
|
|
2013-11-19 00:57:56 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_CTOR_DTOR\n\n";
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit operand name mappings");
|
TableGen: Generate a function for getting operand indices based on their defined names
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
2013-06-25 21:22:09 +00:00
|
|
|
emitOperandNameMappings(OS, Target, NumberedInstructions);
|
2013-11-17 21:24:41 +00:00
|
|
|
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit operand type mappings");
|
2019-07-16 22:10:16 +00:00
|
|
|
emitOperandTypeMappings(OS, Target, NumberedInstructions);
|
2018-05-25 16:02:43 +00:00
|
|
|
|
[M68k][TableGen](1/8) TableGen related changes
- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information
For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792
The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88385
2021-03-07 16:30:54 -08:00
|
|
|
Records.startTimer("Emit logical operand size mappings");
|
|
|
|
emitLogicalOperandSizeMappings(OS, TargetName, NumberedInstructions);
|
|
|
|
|
|
|
|
Records.startTimer("Emit logical operand type mappings");
|
|
|
|
emitLogicalOperandTypeMappings(OS, TargetName, NumberedInstructions);
|
|
|
|
|
2020-12-03 09:58:37 -05:00
|
|
|
Records.startTimer("Emit helper methods");
|
2018-08-14 18:36:54 +00:00
|
|
|
emitMCIIHelperMethods(OS, TargetName);
|
[CodeGen] Move instruction predicate verification to emitInstruction
D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.
This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.
The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.
Recommitted with some fixes for the leftover MCII variables in release
builds.
Differential Revision: https://reviews.llvm.org/D129506
2022-07-14 09:33:28 +01:00
|
|
|
|
|
|
|
Records.startTimer("Emit verifier methods");
|
|
|
|
emitFeatureVerifier(OS, Target);
|
2003-10-05 19:27:59 +00:00
|
|
|
}
|
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
void InstrInfoEmitter::emitRecord(
|
2024-09-18 22:27:26 -07:00
|
|
|
const CodeGenInstruction &Inst, unsigned Num, const Record *InstrInfo,
|
|
|
|
std::map<std::vector<const Record *>, unsigned> &EmittedLists,
|
2023-01-12 21:02:23 +00:00
|
|
|
const OperandInfoMapTy &OperandInfoMap, raw_ostream &OS) {
|
2008-01-06 01:53:37 +00:00
|
|
|
int MinOperands = 0;
|
2012-10-12 17:57:35 +00:00
|
|
|
if (!Inst.Operands.empty())
|
2005-08-19 00:59:49 +00:00
|
|
|
// Each logical operand can be multiple MI operands.
|
2010-11-01 04:03:32 +00:00
|
|
|
MinOperands =
|
|
|
|
Inst.Operands.back().MIOperandNo + Inst.Operands.back().MINumOperands;
|
2024-04-16 15:20:32 -04:00
|
|
|
// Even the logical output operand may be multiple MI operands.
|
|
|
|
int DefOperands = 0;
|
|
|
|
if (Inst.Operands.NumDefs) {
|
|
|
|
auto &Opnd = Inst.Operands[Inst.Operands.NumDefs - 1];
|
|
|
|
DefOperands = Opnd.MIOperandNo + Opnd.MINumOperands;
|
|
|
|
}
|
2008-05-29 19:57:41 +00:00
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
OS << " { ";
|
2024-04-16 15:20:32 -04:00
|
|
|
OS << Num << ",\t" << MinOperands << ",\t" << DefOperands << ",\t"
|
2015-05-28 18:03:07 +00:00
|
|
|
<< Inst.TheDef->getValueAsInt("Size") << ",\t"
|
2023-01-12 07:38:13 +00:00
|
|
|
<< SchedModels.getSchedClassIdx(Inst) << ",\t";
|
|
|
|
|
2024-09-18 22:27:26 -07:00
|
|
|
const CodeGenTarget &Target = CDP.getTargetInfo();
|
2023-01-12 21:02:23 +00:00
|
|
|
|
2023-01-12 07:38:13 +00:00
|
|
|
// Emit the implicit use/def list...
|
|
|
|
OS << Inst.ImplicitUses.size() << ",\t" << Inst.ImplicitDefs.size() << ",\t";
|
2024-09-18 22:27:26 -07:00
|
|
|
std::vector<const Record *> ImplicitOps = Inst.ImplicitUses;
|
2023-01-12 07:38:13 +00:00
|
|
|
llvm::append_range(ImplicitOps, Inst.ImplicitDefs);
|
2023-01-12 21:02:23 +00:00
|
|
|
OS << Target.getName() << "ImpOpBase + " << EmittedLists[ImplicitOps]
|
|
|
|
<< ",\t";
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2023-01-12 21:02:23 +00:00
|
|
|
// Emit the operand info offset.
|
|
|
|
OperandInfoTy OperandInfo = GetOperandInfo(Inst);
|
|
|
|
OS << OperandInfoMap.find(OperandInfo)->second << ",\t0";
|
[MachineOperand][Target] MachineOperand::isRenamable semantics changes
Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.
Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).
Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.
Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.
Clear the IsRenamable bit when changing an operand's register value.
Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.
Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.
Reviewers: qcolombet, MatzeB
Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D43042
llvm-svn: 325931
2018-02-23 18:25:08 +00:00
|
|
|
|
2015-02-26 00:00:33 +00:00
|
|
|
// Emit all of the target independent flags...
|
2019-10-07 18:43:29 +00:00
|
|
|
if (Inst.isPreISelOpcode)
|
|
|
|
OS << "|(1ULL<<MCID::PreISelOpcode)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isPseudo)
|
|
|
|
OS << "|(1ULL<<MCID::Pseudo)";
|
2022-03-18 13:07:13 +08:00
|
|
|
if (Inst.isMeta)
|
|
|
|
OS << "|(1ULL<<MCID::Meta)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isReturn)
|
|
|
|
OS << "|(1ULL<<MCID::Return)";
|
2018-08-21 19:44:11 +00:00
|
|
|
if (Inst.isEHScopeReturn)
|
|
|
|
OS << "|(1ULL<<MCID::EHScopeReturn)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isBranch)
|
|
|
|
OS << "|(1ULL<<MCID::Branch)";
|
|
|
|
if (Inst.isIndirectBranch)
|
|
|
|
OS << "|(1ULL<<MCID::IndirectBranch)";
|
|
|
|
if (Inst.isCompare)
|
|
|
|
OS << "|(1ULL<<MCID::Compare)";
|
|
|
|
if (Inst.isMoveImm)
|
|
|
|
OS << "|(1ULL<<MCID::MoveImm)";
|
2018-05-23 15:28:28 +00:00
|
|
|
if (Inst.isMoveReg)
|
|
|
|
OS << "|(1ULL<<MCID::MoveReg)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isBitcast)
|
|
|
|
OS << "|(1ULL<<MCID::Bitcast)";
|
2016-09-14 08:20:03 +00:00
|
|
|
if (Inst.isAdd)
|
|
|
|
OS << "|(1ULL<<MCID::Add)";
|
2018-07-13 15:19:33 +00:00
|
|
|
if (Inst.isTrap)
|
|
|
|
OS << "|(1ULL<<MCID::Trap)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isSelect)
|
|
|
|
OS << "|(1ULL<<MCID::Select)";
|
|
|
|
if (Inst.isBarrier)
|
|
|
|
OS << "|(1ULL<<MCID::Barrier)";
|
|
|
|
if (Inst.hasDelaySlot)
|
|
|
|
OS << "|(1ULL<<MCID::DelaySlot)";
|
|
|
|
if (Inst.isCall)
|
|
|
|
OS << "|(1ULL<<MCID::Call)";
|
|
|
|
if (Inst.canFoldAsLoad)
|
|
|
|
OS << "|(1ULL<<MCID::FoldableAsLoad)";
|
|
|
|
if (Inst.mayLoad)
|
|
|
|
OS << "|(1ULL<<MCID::MayLoad)";
|
|
|
|
if (Inst.mayStore)
|
|
|
|
OS << "|(1ULL<<MCID::MayStore)";
|
2019-06-05 22:33:10 +00:00
|
|
|
if (Inst.mayRaiseFPException)
|
|
|
|
OS << "|(1ULL<<MCID::MayRaiseFPException)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isPredicable)
|
|
|
|
OS << "|(1ULL<<MCID::Predicable)";
|
|
|
|
if (Inst.isConvertibleToThreeAddress)
|
|
|
|
OS << "|(1ULL<<MCID::ConvertibleTo3Addr)";
|
|
|
|
if (Inst.isCommutable)
|
|
|
|
OS << "|(1ULL<<MCID::Commutable)";
|
|
|
|
if (Inst.isTerminator)
|
|
|
|
OS << "|(1ULL<<MCID::Terminator)";
|
|
|
|
if (Inst.isReMaterializable)
|
|
|
|
OS << "|(1ULL<<MCID::Rematerializable)";
|
|
|
|
if (Inst.isNotDuplicable)
|
|
|
|
OS << "|(1ULL<<MCID::NotDuplicable)";
|
|
|
|
if (Inst.Operands.hasOptionalDef)
|
|
|
|
OS << "|(1ULL<<MCID::HasOptionalDef)";
|
|
|
|
if (Inst.usesCustomInserter)
|
|
|
|
OS << "|(1ULL<<MCID::UsesCustomInserter)";
|
|
|
|
if (Inst.hasPostISelHook)
|
|
|
|
OS << "|(1ULL<<MCID::HasPostISelHook)";
|
|
|
|
if (Inst.Operands.isVariadic)
|
|
|
|
OS << "|(1ULL<<MCID::Variadic)";
|
|
|
|
if (Inst.hasSideEffects)
|
|
|
|
OS << "|(1ULL<<MCID::UnmodeledSideEffects)";
|
|
|
|
if (Inst.isAsCheapAsAMove)
|
|
|
|
OS << "|(1ULL<<MCID::CheapAsAMove)";
|
[MachineOperand][Target] MachineOperand::isRenamable semantics changes
Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.
Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).
Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.
Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.
Clear the IsRenamable bit when changing an operand's register value.
Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.
Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.
Reviewers: qcolombet, MatzeB
Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D43042
llvm-svn: 325931
2018-02-23 18:25:08 +00:00
|
|
|
if (!Target.getAllowRegisterRenaming() || Inst.hasExtraSrcRegAllocReq)
|
|
|
|
OS << "|(1ULL<<MCID::ExtraSrcRegAllocReq)";
|
|
|
|
if (!Target.getAllowRegisterRenaming() || Inst.hasExtraDefRegAllocReq)
|
|
|
|
OS << "|(1ULL<<MCID::ExtraDefRegAllocReq)";
|
2015-05-28 18:33:39 +00:00
|
|
|
if (Inst.isRegSequence)
|
|
|
|
OS << "|(1ULL<<MCID::RegSequence)";
|
|
|
|
if (Inst.isExtractSubreg)
|
|
|
|
OS << "|(1ULL<<MCID::ExtractSubreg)";
|
|
|
|
if (Inst.isInsertSubreg)
|
|
|
|
OS << "|(1ULL<<MCID::InsertSubreg)";
|
|
|
|
if (Inst.isConvergent)
|
|
|
|
OS << "|(1ULL<<MCID::Convergent)";
|
2018-12-03 10:32:42 +00:00
|
|
|
if (Inst.variadicOpsAreDefs)
|
|
|
|
OS << "|(1ULL<<MCID::VariadicOpsAreDefs)";
|
2019-11-14 13:11:34 -08:00
|
|
|
if (Inst.isAuthenticated)
|
|
|
|
OS << "|(1ULL<<MCID::Authenticated)";
|
2003-10-05 19:27:59 +00:00
|
|
|
|
|
|
|
// Emit all of the target-specific flags...
|
2011-07-29 22:43:06 +00:00
|
|
|
BitsInit *TSF = Inst.TheDef->getValueAsBitsInit("TSFlags");
|
2012-10-25 20:33:17 +00:00
|
|
|
if (!TSF)
|
[tablegen] Add locations to many PrintFatalError() calls
Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this. In the process, I
noticed quite a few places elsewhere in TableGen that also neglected to include
a relevant location.
This patch adds locations to errors that relate to a specific record (or a
field within it) and also have easy access to the relevant location. This is
particularly useful when multiclasses are involved as many of these errors
refer to the full name of a record and it's difficult to guess which substring
is grep-able.
Unfortunately, tablegen currently only supports Record granularity so it's not
currently possible to point at a specific Init so these sometimes point at the
record that caused the error rather than the precise origin of the error.
Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle
Reviewed By: nhaehnle
Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58077
llvm-svn: 353862
2019-02-12 17:36:57 +00:00
|
|
|
PrintFatalError(Inst.TheDef->getLoc(), "no TSFlags?");
|
2010-04-05 03:10:20 +00:00
|
|
|
uint64_t Value = 0;
|
|
|
|
for (unsigned i = 0, e = TSF->getNumBits(); i != e; ++i) {
|
2016-12-12 22:23:53 +00:00
|
|
|
if (const auto *Bit = dyn_cast<BitInit>(TSF->getBit(i)))
|
2010-04-05 03:10:20 +00:00
|
|
|
Value |= uint64_t(Bit->getValue()) << i;
|
|
|
|
else
|
[tablegen] Add locations to many PrintFatalError() calls
Summary:
While working on the GISel Combiner, I noticed I was producing location-less
error messages fairly often and set about fixing this. In the process, I
noticed quite a few places elsewhere in TableGen that also neglected to include
a relevant location.
This patch adds locations to errors that relate to a specific record (or a
field within it) and also have easy access to the relevant location. This is
particularly useful when multiclasses are involved as many of these errors
refer to the full name of a record and it's difficult to guess which substring
is grep-able.
Unfortunately, tablegen currently only supports Record granularity so it's not
currently possible to point at a specific Init so these sometimes point at the
record that caused the error rather than the precise origin of the error.
Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, nhaehnle
Reviewed By: nhaehnle
Subscribers: jdoerfert, nhaehnle, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58077
llvm-svn: 353862
2019-02-12 17:36:57 +00:00
|
|
|
PrintFatalError(Inst.TheDef->getLoc(),
|
|
|
|
"Invalid TSFlags bit in " + Inst.TheDef->getName());
|
2010-04-05 03:10:20 +00:00
|
|
|
}
|
|
|
|
OS << ", 0x";
|
|
|
|
OS.write_hex(Value);
|
2023-01-12 21:02:23 +00:00
|
|
|
OS << "ULL";
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2010-04-05 03:10:20 +00:00
|
|
|
OS << " }, // Inst #" << Num << " = " << Inst.TheDef->getName() << "\n";
|
2003-10-05 19:27:59 +00:00
|
|
|
}
|
2011-06-28 20:07:07 +00:00
|
|
|
|
|
|
|
// emitEnums - Print out enum values for all of the instructions.
|
|
|
|
void InstrInfoEmitter::emitEnums(raw_ostream &OS) {
|
2016-02-11 07:39:25 +00:00
|
|
|
OS << "#ifdef GET_INSTRINFO_ENUM\n";
|
2011-06-28 20:07:07 +00:00
|
|
|
OS << "#undef GET_INSTRINFO_ENUM\n";
|
|
|
|
|
|
|
|
OS << "namespace llvm {\n\n";
|
|
|
|
|
2020-05-23 11:55:20 -04:00
|
|
|
const CodeGenTarget &Target = CDP.getTargetInfo();
|
2011-06-28 20:07:07 +00:00
|
|
|
|
|
|
|
// We must emit the PHI opcode first...
|
2017-07-07 06:22:35 +00:00
|
|
|
StringRef Namespace = Target.getInstNamespace();
|
2012-04-11 21:02:30 +00:00
|
|
|
|
2015-05-11 22:17:13 +00:00
|
|
|
if (Namespace.empty())
|
|
|
|
PrintFatalError("No instructions defined!");
|
2011-06-28 20:07:07 +00:00
|
|
|
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
|
|
|
OS << " enum {\n";
|
2014-04-18 02:09:07 +00:00
|
|
|
unsigned Num = 0;
|
2016-02-11 07:39:22 +00:00
|
|
|
for (const CodeGenInstruction *Inst : Target.getInstructionsByEnumValue())
|
2024-02-07 21:04:14 -06:00
|
|
|
OS << " " << Inst->TheDef->getName()
|
|
|
|
<< "\t= " << (Num = Target.getInstrIntValue(Inst->TheDef)) << ",\n";
|
|
|
|
OS << " INSTRUCTION_LIST_END = " << Num + 1 << "\n";
|
2014-11-23 09:40:10 +00:00
|
|
|
OS << " };\n\n";
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2017-12-13 07:26:17 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_ENUM\n\n";
|
|
|
|
|
|
|
|
OS << "#ifdef GET_INSTRINFO_SCHED_ENUM\n";
|
|
|
|
OS << "#undef GET_INSTRINFO_SCHED_ENUM\n";
|
|
|
|
OS << "namespace llvm {\n\n";
|
|
|
|
OS << "namespace " << Namespace << " {\n";
|
2013-09-03 19:43:28 +00:00
|
|
|
OS << "namespace Sched {\n";
|
|
|
|
OS << " enum {\n";
|
2014-04-18 02:09:07 +00:00
|
|
|
Num = 0;
|
|
|
|
for (const auto &Class : SchedModels.explicit_classes())
|
|
|
|
OS << " " << Class.Name << "\t= " << Num++ << ",\n";
|
2016-02-11 07:39:22 +00:00
|
|
|
OS << " SCHED_LIST_END = " << Num << "\n";
|
2014-11-23 09:40:10 +00:00
|
|
|
OS << " };\n";
|
2019-08-25 10:47:30 +00:00
|
|
|
OS << "} // end namespace Sched\n";
|
|
|
|
OS << "} // end namespace " << Namespace << "\n";
|
|
|
|
OS << "} // end namespace llvm\n";
|
2011-06-28 20:07:07 +00:00
|
|
|
|
2017-12-13 07:26:17 +00:00
|
|
|
OS << "#endif // GET_INSTRINFO_SCHED_ENUM\n\n";
|
2011-06-28 20:07:07 +00:00
|
|
|
}
|
2012-06-11 15:37:55 +00:00
|
|
|
|
2023-02-19 14:30:14 +09:00
|
|
|
static void EmitInstrInfo(RecordKeeper &RK, raw_ostream &OS) {
|
2020-12-03 09:58:37 -05:00
|
|
|
RK.startTimer("Analyze DAG patterns");
|
2012-06-11 15:37:55 +00:00
|
|
|
InstrInfoEmitter(RK).run(OS);
|
2020-12-03 09:58:37 -05:00
|
|
|
RK.startTimer("Emit map table");
|
2012-10-25 15:54:06 +00:00
|
|
|
EmitMapTable(RK, OS);
|
2012-06-11 15:37:55 +00:00
|
|
|
}
|
|
|
|
|
2023-02-19 14:30:14 +09:00
|
|
|
static TableGen::Emitter::Opt X("gen-instr-info", EmitInstrInfo,
|
|
|
|
"Generate instruction descriptions");
|