ed3597e2f7
There are two classes of operands that DecoderEmitter cannot currently
handle:
1. Operands that do not participate in instruction encoding.
2. Operands whose encoding contains only 1s and 0s.
Because of this, targets developed various workarounds. Some targets
insert missing operands after an instruction has been (incompletely)
decoded, other take into account the missing operands when printing the
instruction. Some targets do neither of that and fail to correctly
disassemble some instructions.
This patch makes it possible to decode both classes of operands and
allows to remove existing workarounds.
For the case of operand with no contribution to instruction encoding,
one should now add `bits<0> OpName` field to instruction encoding
record. This will make DecoderEmitter generate a call to the decoder
function specified by the operand's DecoderMethod. The function has a
signature different from the usual one and looks like this:
```
static DecodeStatus DecodeImm42Operand(MCInst &Inst, const MCDisassembler *Decoder) {
Inst.addOperand(MCOperand::createImm(42));
return DecodeStatus::Success;
}
```
Notably, encoding bits are not passed to it (since there are none).
There is nothing special about the second case, the operand bits are
passed as usual. The difference is that before this change, the function
was not called if all the bits of the operand were known (no '?' in the
operand encoding).
There are two options controlling the behavior. Passing an option
enables the old behavior. They exist to allow smooth transition to the
new behavior. They are temporary (yeah, I know) and will be removed once
all targets migrate, possibly giving some more time to downstream
targets.
Subsequent patches in the stack enable the new behavior on some in-tree
targets.
LLVM TableGen
The purpose of TableGen is to generate complex output files based on information from source files that are significantly easier to code than the output files would be, and also easier to maintain and modify over time.
The information is coded in a declarative style involving classes and records, which are then processed by TableGen.
class Hello <string _msg> {
string msg = !strconcat("Hello ", _msg);
}
def HelloWorld: Hello<"world!"> {}
------------- Classes -----------------
class Hello<string Hello:_msg = ?> {
string msg = !strconcat("Hello ", Hello:_msg);
}
------------- Defs -----------------
def HelloWorld { // Hello
string msg = "Hello world!";
}
Try this example on Compiler Explorer.
The internalized records are passed on to various backends, which extract information from a subset of the records and generate one or more output files.
These output files are typically .inc files for C++, but may be any type of file that the backend developer needs.
Resources for learning the language:
- TableGen Overview
- Programmer's reference guide
- Tutorial
- Tools for Learning LLVM TableGen
- Lessons in TableGen (video), slides
- Improving Your TableGen Descriptions (video), slides
Writing TableGen backends:
- TableGen Backend Developer's Guide
- How to write a TableGen backend (video), slides, also available as a notebook.
TableGen in MLIR:
Useful tools: