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.
PR 156125 removed the escape (backslash) in front of '$' for all quoted
strings. It has since been pointed out this should only happen for
double-quoted strings. This PR fixes that.
LLDB allows creation of 'persistent' variables, with names that start
with '$'. The lit internal shell was escaping the '$', making it '\\$',
in some CHECK lines, which causes an LLDB test,
TestExprWithSideEffectOnConvenienceVar, to fail when using the lit
internal shell.
Further explanation of the failing LLDB test: LLDB convenience variables
start with '$'. The test passes several quoted commands that use and
update convenience variables to lldb as arguments to be run in batch
mode. The tool that packages up the complete string and passes it to the
lit internal shell lexer for lexing inserts a backslash in front of the
'$' before passing the string in for lexing. The lexer was passing this
change along, causing the tests to fail.
This PR fixes the issue by having the lexer remove the newly added
escape on the '$'.
As noted in #153256, TableGen is generating reserved names for
RuntimeLibcalls, which resulted in a build failure for Arm64EC since
`vcruntime.h` defines `__security_check_cookie` as a macro.
To avoid using reserved names, all impl names will now be prefixed with
`Impl_`.
`NumLibcallImpls` was lifted out as a `constexpr size_t` instead of
being an enum field.
While I was churning the dependent code, I also removed the TODO to move
the impl enum into its own namespace and use an `enum class`: I
experimented with using an `enum class` and adding a namespace, but we
decided it was too verbose so it was dropped.
PR #148287 removed the "\s*" before ".Lfunc_end" for AArch64, which
broke `update_llc_test_checks.py` for a number of tests including:
- `llvm/test/CodeGen/AArch64/sme-za-exceptions.ll`
- `llvm/test/CodeGen/AArch64/win-sve.ll`
This patch adds the "\s*" back.
Move `InsnBitWidth` template into anonymous namespace in the generated
code and move template specialization of `InsnBitWidth` to anonymous
namespace as well, and drop `static` for them. This makes `InsnBitWidth`
completely private to each target and fixes the "explicit specialization
cannot have a storage class" warning as well as any potential linker
errors if `InsnBitWidth` is kept in the `llvm::MCD` namespace.
This change adds an option to specialize decoders per bitwidth, which
can help reduce the (compiled) code size of the decoder code.
**Current state**:
Currently, the code generated by the decoder emitter consists of two key
functions: `decodeInstruction` which is the entry point into the
generated code and `decodeToMCInst` which is invoked when a decode op is
reached while traversing through the decoder table. Both functions are
templated on `InsnType` which is the raw instruction bits that are
supplied to `decodeInstruction`.
Several backends call `decodeInstruction` with different `InsnType`
types, leading to several template instantiations of these functions in
the final code. As an example, AMDGPU instantiates this function with
type `DecoderUInt128` type for decoding 96/128-bit instructions,
`uint64_t` for decoding 64-bit instructions, and `uint32_t` for decoding
32-bit instructions. Since there is just one `decodeToMCInst` in the
generated code, it has code that handles decoding for *all* instruction
sizes. However, the decoders emitted for different instructions sizes
rarely have any intersection with each other. That means, in the AMDGPU
case, the instantiation with InsnType == DecoderUInt128 has decoder code
for 32/64-bit instructions that is *never exercised*. Conversely, the
instantiation with InsnType == uint64_t has decoder code for
128/96/32-bit instructions that is never exercised. This leads to
unnecessary dead code in the generated disassembler binary (that the
compiler cannot eliminate by itself).
**New state**:
With this change, we introduce an option
`specialize-decoders-per-bitwidth`. Under this mode, the DecoderEmitter
will generate several versions of `decodeToMCInst` function, one for
each bitwidth. The code is still templated, but will require backends to
specify, for each `InsnType` used, the bitwidth of the instruction that
the type is used to represent using a type-trait `InsnBitWidth`. This
will enable the templated code to choose the right variant of
`decodeToMCInst`. Under this mode, a particular instantiation will only
end up instantiating a single variant of `decodeToMCInst` generated and
that will include only those decoders that are applicable to a single
bitwidth, resulting in elimination of the code duplication through
instantiation and a reduction in code size.
Additionally, under this mode, decoders are uniqued only within a given
bitwidth (as opposed to across all bitwidths without this option), so
the decoder index values assigned are smaller, and consume less bytes in
their ULEB128 encoding. As a result, the generated decoder tables can
also reduce in size.
Adopt this feature for the AMDGPU and RISCV backend. In a release build,
this results in a net 55% reduction in the .text size of
libLLVMAMDGPUDisassembler.so and a 5% reduction in the .rodata size. For
RISCV, which today uses a single `uint64_t` type, this results in a 3.7%
increase in code size (expected as we instantiate the code 3 times now).
Actual measured sizes are as follows:
```
Baseline commit: 72c04bb882ad70230bce309c3013d9cc2c99e9a7
Configuration: Ubuntu clang version 18.1.3, release build with asserts disabled.
AMDGPU Before After Change
======================================================
.text 612327 275607 55% reduction
.rodata 369728 351336 5% reduction
RISCV:
======================================================
.text 47407 49187 3.7% increase
.rodata 35768 35839 0.1% increase
```
If a custom operand has MIOperandInfo with >= 2 sub-operands, it is
required that either the operand or its sub-operands have a decoder
method (depending on usage). Require this for single sub-operand
operands as well, since there is no good reason not to.
There are no changes in the generated files.
Currently, complex operands of an instruction are flattened in the resulting DAG of `InstAlias`.
This change makes it required to specify complex operands in `InstAlias` as sub-DAGs:
```
InstAlias<"foo $rd, $rs1, $rs2", (Inst RC:$rd, (ComplexOp RC:$rs1, GR0, 42), SimpleOp:$rs2)>;
```
instead of
```
InstAlias<"foo $rd, $rs1, $rs2", (Inst RC:$rd, RC:$rs1, GR0, 42, SimpleOp:$rs2)>;
```
The advantages of the new syntax are improved readability and more robust type checking, although it is a bit more verbose.
I believe it became no-op with the removal of the "positionally encoded
operands" functionality (b87dc356 is the last commit in the series).
There are no changes in the generated files.
This is causing bot failures that need later investigation, but there
are now dependent patches on top of this that would otherwise be
annoying to pull out.
This reverts commit faa4e35c622c13c7a565b979a6676d6cf3040cd4.
This was originally reverted because it was using a Python 3.9 feature
(umask in subprocess.Popen) when LLVM only requires Python 3.8. This
patch uses os.umask instead, which has been around for longer.
closes#154331
This PR addresses all minimum changes needed to compile LLVM and MLIR
with the c++23 standard.
It is a work in progress and to be reviewed for better methods of
handling the parts of the build broken by c++23.
This patch introduces `SCEVDivisionPrinterPass` and registers it under
the name `print<scev-division>`, primarily for testing purposes. This
pass invokes `SCEVDivision::divide` upon encountering `sdiv`, and prints
the numerator, denominator, quotient, and remainder. It also adds
several test cases, some of which are currently incorrect and require
fixing.
Along with that, this patch added some comments to clarify the behavior
of `SCEVDivision::divide`, as follows:
- This function does NOT actually perform the division
- Given the `Numerator` and `Denominator`, find a pair
`(Quotient, Remainder)` s.t.
`Numerator = Quotient * Denominator + Remainder`
- The common condition `Remainder < Denominator` is NOT necessarily
required
- There may be multiple solutions for `(Quotient, Remainder)`, and this
function finds one of them
- Especially, there is always a trivial solution `(0, Numerator)`
- The following computations may wrap
- The multiplication of `Quotient` and `Denominator`
- The addition of `Quotient * Denominator` and `Remainder`
Related discussion: #154745
On Linux/Mac, `llvm-lit` is configured with a shebang and made
executable so tools like LNT and the test-suite can invoke it directly.
On Windows the build only produces `llvm-lit.py` which cannot be used as
a standalone executable. This caused problems when running the LLVM
test-suite via LNT or buildbots.
This change introduces a new template file `llvm-lit.cmd.in` and updates
`llvm/utils/llvm-lit/CMakeLists.txt` so that a corresponding
`llvm-lit.cmd` is generated in the `build/bin` directory (for both
single-config and multi-config generators). The wrapper simply invokes
the configured Python interpreter on the adjacent `llvm-lit.py` and
propagates the exit code.
This ensures that `llvm-lit` can be used as a direct executable on
Windows just like on Linux without requiring external wrappers or
modifications in buildbot scripts or LNT.
This patch updates PPCInstrInfo::copyPhysReg to support DMR and WACC
register classes and extends the PPCVSXCopy pass to handle specific WACC
copy patterns.
This patch makes it so the revisions that the code format action returns
in its reproducers actually work when applying them locally given the
differences in how revisions are setup in CI.
Fixes#154294
This test case matches against python traceback output, which seems to
vary slightly between versions. This relaxes the constraints a bit to
make the test pass on buildbots.
