2003-10-05 19:27:59 +00:00
|
|
|
//===- CodeEmitterGen.cpp - Code Emitter Generator ------------------------===//
|
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
|
|
|
//
|
2004-08-04 22:07:54 +00:00
|
|
|
// CodeEmitterGen uses the descriptions of instructions and their fields to
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
// construct an automated code emitter: a function called
|
|
|
|
// getBinaryCodeForInstr() that, given a MCInst, returns the value of the
|
|
|
|
// instruction - either as an uint64_t or as an APInt, depending on the
|
|
|
|
// maximum bit width of all Inst definitions.
|
|
|
|
//
|
|
|
|
// In addition, it generates another function called getOperandBitOffset()
|
|
|
|
// that, given a MCInst and an operand index, returns the minimum of indices of
|
|
|
|
// all bits that carry some portion of the respective operand. When the target's
|
|
|
|
// encodeInstruction() stores the instruction in a little-endian byte order, the
|
|
|
|
// returned value is the offset of the start of the operand in the encoded
|
|
|
|
// instruction. Other targets might need to adjust the returned value according
|
|
|
|
// to their encodeInstruction() implementation.
|
2003-10-05 19:27:59 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2024-03-25 09:40:35 +01:00
|
|
|
#include "Common/CodeGenHwModes.h"
|
|
|
|
#include "Common/CodeGenInstruction.h"
|
|
|
|
#include "Common/CodeGenTarget.h"
|
|
|
|
#include "Common/InfoByHwMode.h"
|
|
|
|
#include "Common/VarLenCodeEmitterGen.h"
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
#include "llvm/ADT/APInt.h"
|
2016-11-30 17:48:10 +00:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2006-07-13 21:02:53 +00:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2016-11-30 17:48:10 +00:00
|
|
|
#include "llvm/Support/Casting.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2022-06-10 14:18:29 +01:00
|
|
|
#include "llvm/TableGen/Error.h"
|
2012-12-04 10:37:14 +00:00
|
|
|
#include "llvm/TableGen/Record.h"
|
2012-06-11 15:37:55 +00:00
|
|
|
#include "llvm/TableGen/TableGenBackend.h"
|
2016-11-30 17:48:10 +00:00
|
|
|
#include <cstdint>
|
2010-12-13 01:05:54 +00:00
|
|
|
#include <map>
|
2016-11-30 17:48:10 +00:00
|
|
|
#include <set>
|
2012-06-11 15:37:55 +00:00
|
|
|
#include <string>
|
2016-11-30 17:48:10 +00:00
|
|
|
#include <utility>
|
2012-06-11 15:37:55 +00:00
|
|
|
#include <vector>
|
2016-11-30 17:48:10 +00:00
|
|
|
|
2004-08-01 03:55:39 +00:00
|
|
|
using namespace llvm;
|
2003-11-11 22:41:34 +00:00
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
class CodeEmitterGen {
|
|
|
|
RecordKeeper &Records;
|
2016-11-30 17:48:10 +00:00
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
public:
|
|
|
|
CodeEmitterGen(RecordKeeper &R) : Records(R) {}
|
|
|
|
|
|
|
|
void run(raw_ostream &o);
|
2016-11-30 17:48:10 +00:00
|
|
|
|
2012-06-11 15:37:55 +00:00
|
|
|
private:
|
|
|
|
int getVariableBit(const std::string &VarName, BitsInit *BI, int bit);
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
std::pair<std::string, std::string>
|
|
|
|
getInstructionCases(Record *R, CodeGenTarget &Target);
|
2024-09-09 13:09:53 -07:00
|
|
|
void addInstructionCasesForEncoding(Record *R, const Record *EncodingDef,
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
CodeGenTarget &Target, std::string &Case,
|
|
|
|
std::string &BitOffsetCase);
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
bool addCodeToMergeInOperand(Record *R, BitsInit *BI,
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
const std::string &VarName, std::string &Case,
|
|
|
|
std::string &BitOffsetCase,
|
|
|
|
CodeGenTarget &Target);
|
2012-06-11 15:37:55 +00:00
|
|
|
|
2019-09-19 13:39:54 +00:00
|
|
|
void emitInstructionBaseValues(
|
|
|
|
raw_ostream &o, ArrayRef<const CodeGenInstruction *> NumberedInstructions,
|
2024-05-05 09:08:26 +08:00
|
|
|
CodeGenTarget &Target, unsigned HwMode = DefaultMode);
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
void
|
|
|
|
emitCaseMap(raw_ostream &o,
|
|
|
|
const std::map<std::string, std::vector<std::string>> &CaseMap);
|
2023-04-21 17:42:04 +08:00
|
|
|
unsigned BitWidth = 0u;
|
|
|
|
bool UseAPInt = false;
|
2012-06-11 15:37:55 +00:00
|
|
|
};
|
|
|
|
|
2006-07-13 22:17:08 +00:00
|
|
|
// If the VarBitInit at position 'bit' matches the specified variable then
|
|
|
|
// return the variable bit position. Otherwise return -1.
|
2009-12-15 20:21:44 +00:00
|
|
|
int CodeEmitterGen::getVariableBit(const std::string &VarName, BitsInit *BI,
|
2011-07-29 22:43:06 +00:00
|
|
|
int bit) {
|
2012-10-10 20:24:43 +00:00
|
|
|
if (VarBitInit *VBI = dyn_cast<VarBitInit>(BI->getBit(bit))) {
|
|
|
|
if (VarInit *VI = dyn_cast<VarInit>(VBI->getBitVar()))
|
2010-11-15 06:42:13 +00:00
|
|
|
if (VI->getName() == VarName)
|
|
|
|
return VBI->getBitNum();
|
2012-10-10 20:24:43 +00:00
|
|
|
} else if (VarInit *VI = dyn_cast<VarInit>(BI->getBit(bit))) {
|
2011-04-28 17:51:45 +00:00
|
|
|
if (VI->getName() == VarName)
|
|
|
|
return 0;
|
|
|
|
}
|
2010-10-07 16:56:28 +00:00
|
|
|
|
2006-07-13 21:02:53 +00:00
|
|
|
return -1;
|
2010-10-07 16:56:28 +00:00
|
|
|
}
|
2006-07-13 21:02:53 +00:00
|
|
|
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
// Returns true if it succeeds, false if an error.
|
|
|
|
bool CodeEmitterGen::addCodeToMergeInOperand(Record *R, BitsInit *BI,
|
|
|
|
const std::string &VarName,
|
|
|
|
std::string &Case,
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
std::string &BitOffsetCase,
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
CodeGenTarget &Target) {
|
2010-11-15 06:59:17 +00:00
|
|
|
CodeGenInstruction &CGI = Target.getInstruction(R);
|
|
|
|
|
2010-11-15 07:09:28 +00:00
|
|
|
// Determine if VarName actually contributes to the Inst encoding.
|
|
|
|
int bit = BI->getNumBits() - 1;
|
|
|
|
|
|
|
|
// Scan for a bit that this contributed to.
|
|
|
|
for (; bit >= 0;) {
|
|
|
|
if (getVariableBit(VarName, BI, bit) != -1)
|
|
|
|
break;
|
2024-02-09 09:27:04 +01:00
|
|
|
|
2010-11-15 07:09:28 +00:00
|
|
|
--bit;
|
|
|
|
}
|
2024-02-09 09:27:04 +01:00
|
|
|
|
2010-11-15 07:09:28 +00:00
|
|
|
// If we found no bits, ignore this value, otherwise emit the call to get the
|
|
|
|
// operand encoding.
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
if (bit < 0)
|
|
|
|
return true;
|
|
|
|
|
2010-11-15 07:09:28 +00:00
|
|
|
// If the operand matches by name, reference according to that
|
|
|
|
// operand number. Non-matching operands are assumed to be in
|
|
|
|
// order.
|
|
|
|
unsigned OpIdx;
|
2022-09-05 12:10:21 -04:00
|
|
|
std::pair<unsigned, unsigned> SubOp;
|
|
|
|
if (CGI.Operands.hasSubOperandAlias(VarName, SubOp)) {
|
|
|
|
OpIdx = CGI.Operands[SubOp.first].MIOperandNo + SubOp.second;
|
|
|
|
} else if (CGI.Operands.hasOperandNamed(VarName, OpIdx)) {
|
2010-11-15 07:09:28 +00:00
|
|
|
// Get the machine operand number for the indicated operand.
|
|
|
|
OpIdx = CGI.Operands[OpIdx].MIOperandNo;
|
|
|
|
} else {
|
2023-02-08 10:47:11 -05:00
|
|
|
PrintError(R, Twine("No operand named ") + VarName + " in record " +
|
|
|
|
R->getName());
|
|
|
|
return false;
|
2010-11-15 07:09:28 +00:00
|
|
|
}
|
2022-09-05 12:10:21 -04:00
|
|
|
|
2022-11-08 17:11:04 -05:00
|
|
|
if (CGI.Operands.isFlatOperandNotEmitted(OpIdx)) {
|
|
|
|
PrintError(R,
|
|
|
|
"Operand " + VarName + " used but also marked as not emitted!");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-11-15 07:09:28 +00:00
|
|
|
std::pair<unsigned, unsigned> SO = CGI.Operands.getSubOperandNumber(OpIdx);
|
2022-11-08 17:11:04 -05:00
|
|
|
std::string &EncoderMethodName =
|
|
|
|
CGI.Operands[SO.first].EncoderMethodNames[SO.second];
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
|
|
|
|
if (UseAPInt)
|
|
|
|
Case += " op.clearAllBits();\n";
|
|
|
|
|
2022-11-08 17:11:04 -05:00
|
|
|
Case += " // op: " + VarName + "\n";
|
|
|
|
|
|
|
|
// If the source operand has a custom encoder, use it.
|
2010-11-15 07:09:28 +00:00
|
|
|
if (!EncoderMethodName.empty()) {
|
2022-11-08 17:11:04 -05:00
|
|
|
if (UseAPInt) {
|
|
|
|
Case += " " + EncoderMethodName + "(MI, " + utostr(OpIdx);
|
|
|
|
Case += ", op";
|
|
|
|
} else {
|
|
|
|
Case += " op = " + EncoderMethodName + "(MI, " + utostr(OpIdx);
|
2010-11-15 07:09:28 +00:00
|
|
|
}
|
2022-11-08 17:11:04 -05:00
|
|
|
Case += ", Fixups, STI);\n";
|
2010-11-15 07:09:28 +00:00
|
|
|
} else {
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
if (UseAPInt) {
|
|
|
|
Case +=
|
|
|
|
" getMachineOpValue(MI, MI.getOperand(" + utostr(OpIdx) + ")";
|
|
|
|
Case += ", op, Fixups, STI";
|
|
|
|
} else {
|
|
|
|
Case += " op = getMachineOpValue(MI, MI.getOperand(" +
|
|
|
|
utostr(OpIdx) + ")";
|
|
|
|
Case += ", Fixups, STI";
|
|
|
|
}
|
2010-11-15 07:09:28 +00:00
|
|
|
Case += ");\n";
|
|
|
|
}
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
|
|
|
|
// Precalculate the number of lits this variable contributes to in the
|
|
|
|
// operand. If there is a single lit (consecutive range of bits) we can use a
|
|
|
|
// destructive sequence on APInt that reduces memory allocations.
|
|
|
|
int numOperandLits = 0;
|
|
|
|
for (int tmpBit = bit; tmpBit >= 0;) {
|
|
|
|
int varBit = getVariableBit(VarName, BI, tmpBit);
|
|
|
|
|
|
|
|
// If this bit isn't from a variable, skip it.
|
|
|
|
if (varBit == -1) {
|
|
|
|
--tmpBit;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Figure out the consecutive range of bits covered by this operand, in
|
|
|
|
// order to generate better encoding code.
|
|
|
|
int beginVarBit = varBit;
|
|
|
|
int N = 1;
|
|
|
|
for (--tmpBit; tmpBit >= 0;) {
|
|
|
|
varBit = getVariableBit(VarName, BI, tmpBit);
|
|
|
|
if (varBit == -1 || varBit != (beginVarBit - N))
|
|
|
|
break;
|
|
|
|
++N;
|
|
|
|
--tmpBit;
|
|
|
|
}
|
|
|
|
++numOperandLits;
|
|
|
|
}
|
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
unsigned BitOffset = -1;
|
2010-11-15 07:09:28 +00:00
|
|
|
for (; bit >= 0;) {
|
2010-11-15 06:59:17 +00:00
|
|
|
int varBit = getVariableBit(VarName, BI, bit);
|
2024-02-09 09:27:04 +01:00
|
|
|
|
2010-11-15 06:59:17 +00:00
|
|
|
// If this bit isn't from a variable, skip it.
|
|
|
|
if (varBit == -1) {
|
|
|
|
--bit;
|
|
|
|
continue;
|
|
|
|
}
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
|
2011-01-27 23:08:52 +00:00
|
|
|
// Figure out the consecutive range of bits covered by this operand, in
|
2010-11-15 06:59:17 +00:00
|
|
|
// order to generate better encoding code.
|
|
|
|
int beginInstBit = bit;
|
|
|
|
int beginVarBit = varBit;
|
|
|
|
int N = 1;
|
|
|
|
for (--bit; bit >= 0;) {
|
|
|
|
varBit = getVariableBit(VarName, BI, bit);
|
|
|
|
if (varBit == -1 || varBit != (beginVarBit - N))
|
|
|
|
break;
|
|
|
|
++N;
|
|
|
|
--bit;
|
|
|
|
}
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
|
|
|
|
std::string maskStr;
|
|
|
|
int opShift;
|
|
|
|
|
2019-09-18 18:14:42 +00:00
|
|
|
unsigned loBit = beginVarBit - N + 1;
|
|
|
|
unsigned hiBit = loBit + N;
|
|
|
|
unsigned loInstBit = beginInstBit - N + 1;
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
BitOffset = loInstBit;
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
if (UseAPInt) {
|
2019-09-18 18:14:42 +00:00
|
|
|
std::string extractStr;
|
|
|
|
if (N >= 64) {
|
|
|
|
extractStr = "op.extractBits(" + itostr(hiBit - loBit) + ", " +
|
|
|
|
itostr(loBit) + ")";
|
|
|
|
Case += " Value.insertBits(" + extractStr + ", " +
|
|
|
|
itostr(loInstBit) + ");\n";
|
|
|
|
} else {
|
|
|
|
extractStr = "op.extractBitsAsZExtValue(" + itostr(hiBit - loBit) +
|
|
|
|
", " + itostr(loBit) + ")";
|
|
|
|
Case += " Value.insertBits(" + extractStr + ", " +
|
|
|
|
itostr(loInstBit) + ", " + itostr(hiBit - loBit) + ");\n";
|
|
|
|
}
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
} else {
|
|
|
|
uint64_t opMask = ~(uint64_t)0 >> (64 - N);
|
|
|
|
opShift = beginVarBit - N + 1;
|
|
|
|
opMask <<= opShift;
|
|
|
|
maskStr = "UINT64_C(" + utostr(opMask) + ")";
|
2019-09-18 18:14:42 +00:00
|
|
|
opShift = beginInstBit - beginVarBit;
|
|
|
|
|
|
|
|
if (numOperandLits == 1) {
|
|
|
|
Case += " op &= " + maskStr + ";\n";
|
|
|
|
if (opShift > 0) {
|
|
|
|
Case += " op <<= " + itostr(opShift) + ";\n";
|
|
|
|
} else if (opShift < 0) {
|
|
|
|
Case += " op >>= " + itostr(-opShift) + ";\n";
|
|
|
|
}
|
|
|
|
Case += " Value |= op;\n";
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
} else {
|
2019-09-18 18:14:42 +00:00
|
|
|
if (opShift > 0) {
|
|
|
|
Case += " Value |= (op & " + maskStr + ") << " +
|
|
|
|
itostr(opShift) + ";\n";
|
|
|
|
} else if (opShift < 0) {
|
|
|
|
Case += " Value |= (op & " + maskStr + ") >> " +
|
|
|
|
itostr(-opShift) + ";\n";
|
|
|
|
} else {
|
|
|
|
Case += " Value |= (op & " + maskStr + ");\n";
|
|
|
|
}
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
}
|
2010-11-15 06:59:17 +00:00
|
|
|
}
|
|
|
|
}
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
|
|
|
|
if (BitOffset != (unsigned)-1) {
|
|
|
|
BitOffsetCase += " case " + utostr(OpIdx) + ":\n";
|
|
|
|
BitOffsetCase += " // op: " + VarName + "\n";
|
|
|
|
BitOffsetCase += " return " + utostr(BitOffset) + ";\n";
|
|
|
|
}
|
|
|
|
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
return true;
|
2010-11-15 06:59:17 +00:00
|
|
|
}
|
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
std::pair<std::string, std::string>
|
|
|
|
CodeEmitterGen::getInstructionCases(Record *R, CodeGenTarget &Target) {
|
|
|
|
std::string Case, BitOffsetCase;
|
|
|
|
|
2024-05-05 09:08:26 +08:00
|
|
|
auto append = [&](const std::string &S) {
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
Case += S;
|
|
|
|
BitOffsetCase += S;
|
|
|
|
};
|
|
|
|
|
2019-09-19 13:39:54 +00:00
|
|
|
if (const RecordVal *RV = R->getValue("EncodingInfos")) {
|
|
|
|
if (auto *DI = dyn_cast_or_null<DefInit>(RV->getValue())) {
|
|
|
|
const CodeGenHwModes &HWM = Target.getHwModes();
|
|
|
|
EncodingInfoByHwMode EBM(DI->getDef(), HWM);
|
2024-05-05 09:08:26 +08:00
|
|
|
|
|
|
|
// Invoke the interface to obtain the HwMode ID controlling the
|
|
|
|
// EncodingInfo for the current subtarget. This interface will
|
|
|
|
// mask off irrelevant HwMode IDs.
|
|
|
|
append(" unsigned HwMode = "
|
|
|
|
"STI.getHwMode(MCSubtargetInfo::HwMode_EncodingInfo);\n");
|
|
|
|
Case += " switch (HwMode) {\n";
|
|
|
|
Case += " default: llvm_unreachable(\"Unknown hardware mode!\"); "
|
|
|
|
"break;\n";
|
|
|
|
for (auto &[ModeId, Encoding] : EBM) {
|
|
|
|
if (ModeId == DefaultMode) {
|
|
|
|
Case +=
|
|
|
|
" case " + itostr(DefaultMode) + ": InstBitsByHw = InstBits";
|
|
|
|
} else {
|
|
|
|
Case += " case " + itostr(ModeId) +
|
|
|
|
": InstBitsByHw = InstBits_" +
|
|
|
|
std::string(HWM.getMode(ModeId).Name);
|
|
|
|
}
|
|
|
|
Case += "; break;\n";
|
|
|
|
}
|
|
|
|
Case += " };\n";
|
|
|
|
|
|
|
|
// We need to remodify the 'Inst' value from the table we found above.
|
|
|
|
if (UseAPInt) {
|
|
|
|
int NumWords = APInt::getNumWords(BitWidth);
|
|
|
|
Case += " Inst = APInt(" + itostr(BitWidth);
|
|
|
|
Case += ", ArrayRef(InstBitsByHw + opcode * " + itostr(NumWords) +
|
|
|
|
", " + itostr(NumWords);
|
|
|
|
Case += "));\n";
|
|
|
|
Case += " Value = Inst;\n";
|
|
|
|
} else {
|
|
|
|
Case += " Value = InstBitsByHw[opcode];\n";
|
|
|
|
}
|
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
append(" switch (HwMode) {\n");
|
|
|
|
append(" default: llvm_unreachable(\"Unhandled HwMode\");\n");
|
2024-05-05 09:08:26 +08:00
|
|
|
for (auto &[ModeId, Encoding] : EBM) {
|
|
|
|
append(" case " + itostr(ModeId) + ": {\n");
|
|
|
|
addInstructionCasesForEncoding(R, Encoding, Target, Case,
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
BitOffsetCase);
|
|
|
|
append(" break;\n");
|
|
|
|
append(" }\n");
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
append(" }\n");
|
2024-02-14 13:16:20 +00:00
|
|
|
return std::pair(std::move(Case), std::move(BitOffsetCase));
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
|
|
|
}
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
addInstructionCasesForEncoding(R, R, Target, Case, BitOffsetCase);
|
2024-02-14 13:16:20 +00:00
|
|
|
return std::pair(std::move(Case), std::move(BitOffsetCase));
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
void CodeEmitterGen::addInstructionCasesForEncoding(
|
2024-09-09 13:09:53 -07:00
|
|
|
Record *R, const Record *EncodingDef, CodeGenTarget &Target,
|
|
|
|
std::string &Case, std::string &BitOffsetCase) {
|
2019-09-19 13:39:54 +00:00
|
|
|
BitsInit *BI = EncodingDef->getValueAsBitsInit("Inst");
|
[TableGen] Optionally forbid overlap between named and positional operands
There are currently two schemes for mapping instruction operands to
instruction-format variables for generating the instruction encoders and
decoders for the assembler and disassembler respectively: a) to map by name and
b) to map by position.
In the long run, we'd like to remove the position-based scheme and use only
name-based mapping. Unfortunately, the name-based scheme currently cannot deal
with complex operands (those with suboperands), and so we currently must use
the position-based scheme for those. On the other hand, the position-based
scheme cannot deal with (register) variables that are split into multiple
ranges. An upcoming commit to the PowerPC backend (adding VSX support) will
require this capability. While we could teach the position-based scheme to
handle that, since we'd like to move away from the position-based mapping
generally, it seems silly to teach it new tricks now. What makes more sense is
to allow for partial transitioning: use the name-based mapping when possible,
and only use the position-based scheme when necessary.
Now the problem is that mixing the two sensibly was not possible: the
position-based mapping would map based on position, but would not skip those
variables that were mapped by name. Instead, the two sets of assignments would
overlap. However, I cannot currently change the current behavior, because there
are some backends that rely on it [I think mistakenly, but I'll send a message
to llvmdev about that]. So I've added a new TableGen bit variable:
noNamedPositionallyEncodedOperands, that can be used to cause the
position-based mapping to skip variables mapped by name.
llvm-svn: 203767
2014-03-13 07:57:54 +00:00
|
|
|
|
2010-11-15 06:59:17 +00:00
|
|
|
// Loop over all of the fields in the instruction, determining which are the
|
|
|
|
// operands to the instruction.
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
bool Success = true;
|
2023-07-20 13:28:28 +02:00
|
|
|
size_t OrigBitOffsetCaseSize = BitOffsetCase.size();
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
BitOffsetCase += " switch (OpNum) {\n";
|
2023-07-20 13:28:28 +02:00
|
|
|
size_t BitOffsetCaseSizeBeforeLoop = BitOffsetCase.size();
|
2019-09-19 13:39:54 +00:00
|
|
|
for (const RecordVal &RV : EncodingDef->getValues()) {
|
2010-11-15 06:59:17 +00:00
|
|
|
// Ignore fixed fields in the record, we're looking for values like:
|
|
|
|
// bits<5> RST = { ?, ?, ?, ?, ? };
|
2020-12-31 14:50:51 -05:00
|
|
|
if (RV.isNonconcreteOK() || RV.getValue()->isComplete())
|
2010-11-15 06:59:17 +00:00
|
|
|
continue;
|
2020-01-28 20:23:46 +01:00
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
Success &= addCodeToMergeInOperand(R, BI, std::string(RV.getName()), Case,
|
|
|
|
BitOffsetCase, Target);
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
}
|
2023-07-20 13:28:28 +02:00
|
|
|
// Avoid empty switches.
|
|
|
|
if (BitOffsetCase.size() == BitOffsetCaseSizeBeforeLoop)
|
|
|
|
BitOffsetCase.resize(OrigBitOffsetCaseSize);
|
|
|
|
else
|
|
|
|
BitOffsetCase += " }\n";
|
[TableGen] Add useDeprecatedPositionallyEncodedOperands option.
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
2022-09-20 08:30:20 -04:00
|
|
|
|
|
|
|
if (!Success) {
|
|
|
|
// Dump the record, so we can see what's going on...
|
|
|
|
std::string E;
|
|
|
|
raw_string_ostream S(E);
|
|
|
|
S << "Dumping record for previous error:\n";
|
|
|
|
S << *R;
|
|
|
|
PrintNote(E);
|
2010-11-15 06:59:17 +00:00
|
|
|
}
|
2017-05-31 21:12:46 +00:00
|
|
|
|
|
|
|
StringRef PostEmitter = R->getValueAsString("PostEncoderMethod");
|
2014-01-28 23:13:18 +00:00
|
|
|
if (!PostEmitter.empty()) {
|
2017-05-31 21:12:46 +00:00
|
|
|
Case += " Value = ";
|
|
|
|
Case += PostEmitter;
|
|
|
|
Case += "(MI, Value";
|
2014-09-02 22:28:02 +00:00
|
|
|
Case += ", STI";
|
2014-01-28 23:13:18 +00:00
|
|
|
Case += ");\n";
|
|
|
|
}
|
2010-11-15 06:59:17 +00:00
|
|
|
}
|
|
|
|
|
[CodeEmitter] Support instruction widths > 64 bits
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).
This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).
When Inst.BitWidth > 64 the prototype changes to:
void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);
The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.
Similarly the operand encoding prototype changes to:
getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);
That is, the operand is passed by reference as APInt rather than returned as uint64_t.
To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.
llvm-svn: 371928
2019-09-15 08:35:08 +00:00
|
|
|
static void emitInstBits(raw_ostream &OS, const APInt &Bits) {
|
|
|
|
for (unsigned I = 0; I < Bits.getNumWords(); ++I)
|
|
|
|
OS << ((I > 0) ? ", " : "") << "UINT64_C(" << utostr(Bits.getRawData()[I])
|
|
|
|
<< ")";
|
|
|
|
}
|
|
|
|
|
2019-09-19 13:39:54 +00:00
|
|
|
void CodeEmitterGen::emitInstructionBaseValues(
|
|
|
|
raw_ostream &o, ArrayRef<const CodeGenInstruction *> NumberedInstructions,
|
2024-05-05 09:08:26 +08:00
|
|
|
CodeGenTarget &Target, unsigned HwMode) {
|
2019-09-19 13:39:54 +00:00
|
|
|
const CodeGenHwModes &HWM = Target.getHwModes();
|
2024-05-05 09:08:26 +08:00
|
|
|
if (HwMode == DefaultMode)
|
2019-09-19 13:39:54 +00:00
|
|
|
o << " static const uint64_t InstBits[] = {\n";
|
|
|
|
else
|
2024-02-28 11:47:18 -06:00
|
|
|
o << " static const uint64_t InstBits_"
|
|
|
|
<< HWM.getModeName(HwMode, /*IncludeDefault=*/true) << "[] = {\n";
|
2019-09-19 13:39:54 +00:00
|
|
|
|
|
|
|
for (const CodeGenInstruction *CGI : NumberedInstructions) {
|
|
|
|
Record *R = CGI->TheDef;
|
|
|
|
|
|
|
|
if (R->getValueAsString("Namespace") == "TargetOpcode" ||
|
|
|
|
R->getValueAsBit("isPseudo")) {
|
|
|
|
o << " ";
|
|
|
|
emitInstBits(o, APInt(BitWidth, 0));
|
|
|
|
o << ",\n";
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-09-09 13:09:53 -07:00
|
|
|
const Record *EncodingDef = R;
|
2019-09-19 13:39:54 +00:00
|
|
|
if (const RecordVal *RV = R->getValue("EncodingInfos")) {
|
|
|
|
if (auto *DI = dyn_cast_or_null<DefInit>(RV->getValue())) {
|
|
|
|
EncodingInfoByHwMode EBM(DI->getDef(), HWM);
|
2024-05-05 09:08:26 +08:00
|
|
|
if (EBM.hasMode(HwMode)) {
|
2019-10-09 09:15:34 +00:00
|
|
|
EncodingDef = EBM.get(HwMode);
|
2024-05-05 09:08:26 +08:00
|
|
|
} else {
|
|
|
|
// If the HwMode does not match, then Encoding '0'
|
|
|
|
// should be generated.
|
|
|
|
APInt Value(BitWidth, 0);
|
|
|
|
o << " ";
|
|
|
|
emitInstBits(o, Value);
|
|
|
|
o << "," << '\t' << "// " << R->getName() << "\n";
|
|
|
|
continue;
|
|
|
|
}
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
BitsInit *BI = EncodingDef->getValueAsBitsInit("Inst");
|
|
|
|
|
|
|
|
// Start by filling in fixed values.
|
|
|
|
APInt Value(BitWidth, 0);
|
|
|
|
for (unsigned i = 0, e = BI->getNumBits(); i != e; ++i) {
|
2022-09-18 23:25:58 -07:00
|
|
|
if (auto *B = dyn_cast<BitInit>(BI->getBit(i)); B && B->getValue())
|
|
|
|
Value.setBit(i);
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
|
|
|
o << " ";
|
|
|
|
emitInstBits(o, Value);
|
|
|
|
o << "," << '\t' << "// " << R->getName() << "\n";
|
|
|
|
}
|
|
|
|
o << " UINT64_C(0)\n };\n";
|
|
|
|
}
|
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
void CodeEmitterGen::emitCaseMap(
|
|
|
|
raw_ostream &o,
|
|
|
|
const std::map<std::string, std::vector<std::string>> &CaseMap) {
|
|
|
|
std::map<std::string, std::vector<std::string>>::const_iterator IE, EE;
|
|
|
|
for (IE = CaseMap.begin(), EE = CaseMap.end(); IE != EE; ++IE) {
|
|
|
|
const std::string &Case = IE->first;
|
|
|
|
const std::vector<std::string> &InstList = IE->second;
|
|
|
|
|
|
|
|
for (int i = 0, N = InstList.size(); i < N; i++) {
|
|
|
|
if (i)
|
|
|
|
o << "\n";
|
|
|
|
o << " case " << InstList[i] << ":";
|
|
|
|
}
|
|
|
|
o << " {\n";
|
|
|
|
o << Case;
|
|
|
|
o << " break;\n"
|
|
|
|
<< " }\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-03 00:10:29 +00:00
|
|
|
void CodeEmitterGen::run(raw_ostream &o) {
|
2023-02-19 01:22:38 +09:00
|
|
|
emitSourceFileHeader("Machine Code Emitter", o);
|
|
|
|
|
2010-12-13 00:23:57 +00:00
|
|
|
CodeGenTarget Target(Records);
|
2003-10-05 19:27:59 +00:00
|
|
|
std::vector<Record *> Insts = Records.getAllDerivedDefinitions("Instruction");
|
2010-10-07 16:56:28 +00:00
|
|
|
|
2006-07-13 21:02:53 +00:00
|
|
|
// For little-endian instruction bit encodings, reverse the bit order
|
2013-12-17 22:37:50 +00:00
|
|
|
Target.reverseBitsForLittleEndianEncoding();
|
2010-10-07 16:56:28 +00:00
|
|
|
|
2016-02-01 01:33:42 +00:00
|
|
|
ArrayRef<const CodeGenInstruction *> NumberedInstructions =
|
2010-03-19 00:34:35 +00:00
|
|
|
Target.getInstructionsByEnumValue();
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2024-03-11 08:13:33 -05:00
|
|
|
if (Target.hasVariableLengthEncodings()) {
|
2021-12-06 11:01:17 +08:00
|
|
|
emitVarLenCodeEmitter(Records, o);
|
|
|
|
} else {
|
|
|
|
const CodeGenHwModes &HWM = Target.getHwModes();
|
|
|
|
// The set of HwModes used by instruction encodings.
|
|
|
|
std::set<unsigned> HwModes;
|
|
|
|
BitWidth = 0;
|
|
|
|
for (const CodeGenInstruction *CGI : NumberedInstructions) {
|
|
|
|
Record *R = CGI->TheDef;
|
|
|
|
if (R->getValueAsString("Namespace") == "TargetOpcode" ||
|
|
|
|
R->getValueAsBit("isPseudo"))
|
|
|
|
continue;
|
2004-08-10 20:54:58 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
if (const RecordVal *RV = R->getValue("EncodingInfos")) {
|
|
|
|
if (DefInit *DI = dyn_cast_or_null<DefInit>(RV->getValue())) {
|
|
|
|
EncodingInfoByHwMode EBM(DI->getDef(), HWM);
|
|
|
|
for (auto &KV : EBM) {
|
|
|
|
BitsInit *BI = KV.second->getValueAsBitsInit("Inst");
|
|
|
|
BitWidth = std::max(BitWidth, BI->getNumBits());
|
|
|
|
HwModes.insert(KV.first);
|
|
|
|
}
|
|
|
|
continue;
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
|
|
|
}
|
2021-12-06 11:01:17 +08:00
|
|
|
BitsInit *BI = R->getValueAsBitsInit("Inst");
|
|
|
|
BitWidth = std::max(BitWidth, BI->getNumBits());
|
2019-09-19 13:39:54 +00:00
|
|
|
}
|
2021-12-06 11:01:17 +08:00
|
|
|
UseAPInt = BitWidth > 64;
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Emit function declaration
|
|
|
|
if (UseAPInt) {
|
|
|
|
o << "void " << Target.getName()
|
|
|
|
<< "MCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,\n"
|
|
|
|
<< " SmallVectorImpl<MCFixup> &Fixups,\n"
|
|
|
|
<< " APInt &Inst,\n"
|
|
|
|
<< " APInt &Scratch,\n"
|
|
|
|
<< " const MCSubtargetInfo &STI) const {\n";
|
|
|
|
} else {
|
|
|
|
o << "uint64_t " << Target.getName();
|
|
|
|
o << "MCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,\n"
|
|
|
|
<< " SmallVectorImpl<MCFixup> &Fixups,\n"
|
|
|
|
<< " const MCSubtargetInfo &STI) const {\n";
|
2003-10-05 19:27:59 +00:00
|
|
|
}
|
2019-09-19 13:39:54 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Emit instruction base values
|
2024-05-05 09:08:26 +08:00
|
|
|
emitInstructionBaseValues(o, NumberedInstructions, Target, DefaultMode);
|
2021-12-06 11:01:17 +08:00
|
|
|
if (!HwModes.empty()) {
|
2024-05-05 09:08:26 +08:00
|
|
|
// Emit table for instrs whose encodings are controlled by HwModes.
|
|
|
|
for (unsigned HwMode : HwModes) {
|
|
|
|
if (HwMode == DefaultMode)
|
|
|
|
continue;
|
|
|
|
emitInstructionBaseValues(o, NumberedInstructions, Target, HwMode);
|
2021-12-06 11:01:17 +08:00
|
|
|
}
|
2024-05-05 09:08:26 +08:00
|
|
|
|
|
|
|
// This pointer will be assigned to the HwMode table later.
|
|
|
|
o << " const uint64_t *InstBitsByHw;\n";
|
2021-12-06 11:01:17 +08:00
|
|
|
}
|
2010-11-11 01:19:24 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Map to accumulate all the cases.
|
|
|
|
std::map<std::string, std::vector<std::string>> CaseMap;
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
std::map<std::string, std::vector<std::string>> BitOffsetCaseMap;
|
2005-04-22 00:00:37 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Construct all cases statement for each opcode
|
|
|
|
for (Record *R : Insts) {
|
|
|
|
if (R->getValueAsString("Namespace") == "TargetOpcode" ||
|
|
|
|
R->getValueAsBit("isPseudo"))
|
|
|
|
continue;
|
|
|
|
std::string InstName =
|
|
|
|
(R->getValueAsString("Namespace") + "::" + R->getName()).str();
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
std::string Case, BitOffsetCase;
|
|
|
|
std::tie(Case, BitOffsetCase) = getInstructionCases(R, Target);
|
2021-12-06 11:01:17 +08:00
|
|
|
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
CaseMap[Case].push_back(InstName);
|
|
|
|
BitOffsetCaseMap[BitOffsetCase].push_back(std::move(InstName));
|
2021-12-06 11:01:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Emit initial function code
|
|
|
|
if (UseAPInt) {
|
|
|
|
int NumWords = APInt::getNumWords(BitWidth);
|
|
|
|
o << " const unsigned opcode = MI.getOpcode();\n"
|
|
|
|
<< " if (Scratch.getBitWidth() != " << BitWidth << ")\n"
|
|
|
|
<< " Scratch = Scratch.zext(" << BitWidth << ");\n"
|
2023-01-04 08:28:45 +01:00
|
|
|
<< " Inst = APInt(" << BitWidth << ", ArrayRef(InstBits + opcode * "
|
|
|
|
<< NumWords << ", " << NumWords << "));\n"
|
2021-12-06 11:01:17 +08:00
|
|
|
<< " APInt &Value = Inst;\n"
|
|
|
|
<< " APInt &op = Scratch;\n"
|
|
|
|
<< " switch (opcode) {\n";
|
|
|
|
} else {
|
|
|
|
o << " const unsigned opcode = MI.getOpcode();\n"
|
|
|
|
<< " uint64_t Value = InstBits[opcode];\n"
|
|
|
|
<< " uint64_t op = 0;\n"
|
|
|
|
<< " (void)op; // suppress warning\n"
|
|
|
|
<< " switch (opcode) {\n";
|
|
|
|
}
|
2005-04-22 00:00:37 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Emit each case statement
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
emitCaseMap(o, CaseMap);
|
2003-10-05 19:27:59 +00:00
|
|
|
|
2021-12-06 11:01:17 +08:00
|
|
|
// Default case: unhandled opcode
|
|
|
|
o << " default:\n"
|
|
|
|
<< " std::string msg;\n"
|
|
|
|
<< " raw_string_ostream Msg(msg);\n"
|
|
|
|
<< " Msg << \"Not supported instr: \" << MI;\n"
|
|
|
|
<< " report_fatal_error(Msg.str().c_str());\n"
|
|
|
|
<< " }\n";
|
|
|
|
if (UseAPInt)
|
|
|
|
o << " Inst = Value;\n";
|
|
|
|
else
|
|
|
|
o << " return Value;\n";
|
|
|
|
o << "}\n\n";
|
[TableGen][CodeEmitterGen] Add support for querying operand bit offsets
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
2023-07-20 10:10:16 +02:00
|
|
|
|
|
|
|
o << "#ifdef GET_OPERAND_BIT_OFFSET\n"
|
|
|
|
<< "#undef GET_OPERAND_BIT_OFFSET\n\n"
|
|
|
|
<< "uint32_t " << Target.getName()
|
|
|
|
<< "MCCodeEmitter::getOperandBitOffset(const MCInst &MI,\n"
|
|
|
|
<< " unsigned OpNum,\n"
|
|
|
|
<< " const MCSubtargetInfo &STI) const {\n"
|
|
|
|
<< " switch (MI.getOpcode()) {\n";
|
|
|
|
emitCaseMap(o, BitOffsetCaseMap);
|
|
|
|
o << " }\n"
|
|
|
|
<< " std::string msg;\n"
|
|
|
|
<< " raw_string_ostream Msg(msg);\n"
|
|
|
|
<< " Msg << \"Not supported instr[opcode]: \" << MI << \"[\" << OpNum "
|
|
|
|
"<< \"]\";\n"
|
|
|
|
<< " report_fatal_error(Msg.str().c_str());\n"
|
|
|
|
<< "}\n\n"
|
|
|
|
<< "#endif // GET_OPERAND_BIT_OFFSET\n\n";
|
2021-12-06 11:01:17 +08:00
|
|
|
}
|
2003-10-05 19:27:59 +00:00
|
|
|
}
|
2012-06-11 15:37:55 +00:00
|
|
|
|
2016-11-30 17:48:10 +00:00
|
|
|
} // end anonymous namespace
|
2012-06-11 15:37:55 +00:00
|
|
|
|
2023-02-19 14:30:14 +09:00
|
|
|
static TableGen::Emitter::OptClass<CodeEmitterGen>
|
|
|
|
X("gen-emitter", "Generate machine code emitter");
|