Allow a target to steal the definition of a generic pseudoinstruction
and remap the operands. This works by defining a new instruction, which
will simply swap out the emitted entry in the InstrInfo table.
This is intended to eliminate the C++ half of the implementation
of PointerLikeRegClass. With RegClassByHwMode, the remaining usecase
for PointerLikeRegClass are the common codegen pseudoinstructions.
Every target maintains its own copy of the generic pseudo operand
definitions anyway, so we can stub out the register operands with
an appropriate class instead of waiting for runtime resolution.
In the future we could probably take this a bit further. For example,
there is a similar problem for ADJCALLSTACKUP/DOWN since they depend
on target register definitions for the stack pointer register.
Both conceptually belong to the same subtarget, so it should not
be necessary to pass in the context TargetRegisterInfo to any
TargetInstrInfo member. Add this reference so those superfluous
arguments can be removed.
Most targets placed their TargetRegisterInfo as a member
in TargetInstrInfo. A few had this owned by the TargetSubtargetInfo,
so unify all targets to look the same.
Some instances of the `Operand` class used in Tablegen instruction
definitions expand to a cluster of multiple operands at the MC layer,
such as complex addressing modes involving base + offset + shift, or
clusters of operands describing conditional Arm instructions or
predicated MVE instructions. There's currently no convenient way for C++
code to know the offset of one of those sub-operands from the start of
the cluster: instead it just hard-codes magic numbers like `index+2`,
which is hard to read and fragile.
This patch adds an extra piece of output to `InstrInfoEmitter` to define
those instruction offsets, based on the name of the `Operand` class
instance in Tablegen, and the names assigned to the sub-operands in the
`MIOperandInfo` field. For example, if target Foo were to define
def Bar : Operand {
let MIOperandInfo = (ops GPR:$first, i32imm:$second);
// ...
}
then the new constants would be `Foo::SUBOP_Bar_first` and
`Foo::SUBOP_Bar_second`, defined as 0 and 1 respectively.
As an example, I've converted some magic numbers related to the MVE
predication operand types (`vpred_n` and its superset `vpred_r`) to use
the new named constants in place of the integer literals they previously
used. This is more verbose, but also clearer, because it explains why
the integer is chosen instead of what its value is.
This is a generalization of the LookupPtrRegClass mechanism.
AMDGPU has several use cases for swapping the register class of
instruction operands based on the subtarget, but none of them
really fit into the box of being pointer-like.
The current system requires manual management of an arbitrary integer
ID. For the AMDGPU use case, this would end up being around 40 new
entries to manage.
This just introduces the base infrastructure. I have ports of all
the target specific usage of PointerLikeRegClass ready.
This will make it possible for tablegen to make subtarget
dependent decisions without adding new arguments to every
target.
---------
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
- Replace manual code to convert a `BitsInit` to a uint64_t by using
`convertInitializerToInt` where applicable.
- Add `BitsInit::convertKnownBitsToInt` to handle existing patterns in
DFAEmitter.cpp and RegisterInfoEmitter.cpp.
- Consolidate 3 copies of the same function in X86 emitters into a
single function.
Print the source location of the instruction definition in comment next
to the enum value for each instruction. To make this more readable,
change formatting of the instruction enums to be better aligned.
Example output:
```
VLD4qWB_register_Asm_8 = 573, // (ARMInstrNEON.td:8849)
VMOVD0 = 574, // (ARMInstrNEON.td:6337)
VMOVDcc = 575, // (ARMInstrVFP.td:2466)
VMOVHcc = 576, // (ARMInstrVFP.td:2474)
VMOVQ0 = 577, // (ARMInstrNEON.td:6341)
```
The name is most interesting and if you really need the number you can
use the name to find the entry in the enum or use the first field of the
table row.
This is meant as the inverse of getNamedOperandIdx and returns the
OpName for a given operand index for a given opcode.
---------
Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>
Use direct table lookup instead of a switch over all opcodes.
In my Release+Asserts build this reduced the code size for
AMDGPU::getNamedOperandIdx from 11422 to 80 bytes, and the total size of
all its tables (including the jump table for the switch) from 243564 to
155020 bytes.
- Add various instruction subclass/sub-slice accessors to
`CodeGenTarget`.
- Delete unused `inst_begin` and `inst_end` iterators.
- Rename `Instructions` to `InstructionMap` and `getInstructions` to
`getInstructionMap` to better represent their meaning.
- Use these new accessors in InstrInfoEmitter
- Change InstrInfoEmitter to emit OpName as an enum class
instead of an anonymous enum in the OpName namespace.
- This will help clearly distinguish between values that are
OpNames vs just operand indices and should help avoid
bugs due to confusion between the two.
- Rename OpName::OPERAND_LAST to NUM_OPERAND_NAMES.
- Emit declaration of getOperandIdx() along with the OpName
enum so it doesn't have to be repeated in various headers.
- Also updated AMDGPU, RISCV, and WebAssembly backends
to conform to the new definition of OpName (mostly
mechanical changes).
- Use range for loops and `enumerate` in a few places.
- Use `StringRef` for `TargetName` in `InstrInfoEmitter::run`.
- Use `\n` character for new line instead of string.
- Use StringRef in `InstrNames` (instead of std::string) and
avoid string copies.
- Detect whether logical operand mapping/named operand mappings have
been enabled in a previous pass over instructions and execute the
relevant emission code only if those mappings are enabled.
- For these mappings, skip the fixed set of predefined instructions as
they won't have these mappings enabled.
- Emit operand type mappings only for X86 target, as they are only used
by X86 and look for X86 specific `X86MemOperand`.
- Cleanup `emitOperandTypeMappings` code: remove code to handle empty
instruction list and use range for loops.
- Looks like this sentinel value is used in some downstream backends, so
restore emitting it.
- It now also has the correct value (earlier code may have emitted an
incorrect value for OPERAND_LAST and hence it was removed in
https://github.com/llvm/llvm-project/pull/124960)
- Assign `OpName` enum values in the same alphabetical order in which
they are emitted.
- Get rid of OPERAND_LAST which is not used anywhere.
- Inline `initOperandMapData` into `emitOperandNameMappings` to help see
clearly how various maps are computed.
- Emit the static `OperandMap` table as int8_t when possible. This
should help reduce the static size by 50% in the common case.
- Change maps/vectors to use StringRef instead of std::string to avoid
unnecessary copies.
Adopt scaled indent in PredicateExpander.
Added pre/post inc/dec operators to `indent` and related unit tests.
Verified by comparing *.inc files generated by LLVM build with/without
the change.
- If a def operand includes multiple sub-operands, count them when
generating instr info.
- Found issues in x86 and sparc backends, where memory operands of
store or store-like instructions are wrongly placed in the output
list.
Reviewers: jayfoad, arsenm, Pierre-vh
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/88972
Refactor of the llvm-tblgen source into:
- a "Basic" library, which contains the bare minimum utilities to build
`llvm-min-tablegen`
- a "Common" library which contains all of the helpers for TableGen
backends. Such helpers can be shared by more than one backend, and even
unit tested (e.g. CodeExpander is, maybe we can add more over time)
Fixes#80647
When generating snippets for AArch64 with --opcode-index=-1, the code
generator asserts on opcodes that are not supported according to CPU
features.
The same assertion can be triggered even when generating a serial
snippet for a supported opcode if SERIAL_VIA_NON_MEMORY_INSTR execution
mode is used and an unsupported instruction is chosen as the "other
instruction". Unlike the first case, this one may result in flaky
failures because the other instruction is randomly chosen from the
instructions suitable for serializing execution.
This patch adjusts TableGen emitter for *GenInstrInfo.inc to make
possible to query for opcode availability instead of just asserting on
unsupported ones.
~~
Huawei RRI, OS Lab
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D146303
A function is already emitted in *GenInstrInfo.inc that takes Opcode
number and a set of supported Features and reports fatal error if some
of the required features are missing.
The information about features required by the particular opcode can be
reused by llvm-exegesis, so move its computation info a separate
computeRequiredFeatures() function. Then verifyInstructionPredicates()
can just compare the sets of available and required features computed by
the other functions.
This commit moves the definition of FeatureBitsets[] as well as CEFBS_*
enumerator values (that are indices into FeatureBitsets[] array) inside
the computeRequiredFeatures() function because these are implementation
details of that function. The inclusion of potentially huge
computeRequiredFeatures() function is now controlled by a dedicated
macro that is set for simplicity by TableGen-erated code itself if
`defined(ENABLE_INSTR_PREDICATE_VERIFIER) && !defined(NDEBUG)`.
~~
Huawei RRI, OS Lab
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D148516
This shrinks MCInstrDesc (and hence the whole TargetInsts table) because
we can store a 16-bit offset value to access the operands info, instead
of a pointer. This also reduces the number of relocs that need to be
applied when LLVM is compiled as position-independent code.
Differential Revision: https://reviews.llvm.org/D142219
This shrinks MCInstrDesc (and hence the whole TargetInsts table) because
we can store a 16-bit offset value to access the implicit operands,
instead of a pointer. This also reduces the number of relocs that need
to be applied when LLVM is compiled as position-independent code.
Differential Revision: https://reviews.llvm.org/D142218
