Register classes and immediate predicates in a CompressPat no longer
need to match the compressed instruction. We can now merge most of the
C_*_HINT instructions into their non-HINT equivalents.
I've left c.slli64/srli64/srai6 out to avoid conflict with #150689.
C_NOP_HINT is left out because the spec refers to C_NOP as a separate
instruction from C_ADDI. C_NOP does not allow an immediate operand but
C_NOP_HINT does.
Insn is passed to decodeInstruction which is a template function based
on the type of Insn. By using uint64_t we ensure only one version of
decodeInstruction is created. This reduces the file size of
RISCVDisassembler.cpp.o by ~25% in my local build.
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Target` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
A sub-set of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The bulk of this change is manual additions of `LLVM_ABI` to
`LLVMInitializeX` functions defined in .cpp files under llvm/lib/Target.
Adding `LLVM_ABI` to the function implementation is required here
because they do not `#include "llvm/Support/TargetSelect.h"`, which
contains the declarations for this functions and was already updated
with `LLVM_ABI` in a previous patch. I considered patching these files
with `#include "llvm/Support/TargetSelect.h"` instead, but since
TargetSelect.h is a large file with a bunch of preprocessor x-macro
stuff in it I was concerned it would unnecessarily impact compile times.
In addition, a number of unit tests under llvm/unittests/Target required
additional dependencies to make them build correctly against the LLVM
DLL on Windows using MSVC.
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
This adds assembler/disassembler support for XSfmmbase 0.6 and related
SiFive matrix multiplication extensions based on the spec here
https://www.sifive.com/document-file/xsfmm-matrix-extensions-specification
Functionality-wise, this is the same as the Zvma extension proposal that
SiFive shared with the Attached Matrix Extension Task Group. The
extension names and instruction mnemonics have been changed to use
vendor prefixes.
Note this is a non-conforming extension as the opcodes used here are in
the standard opcode space in OP-V or OP-VE.
---------
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
Spimm in the spec refers to the 2-bit encoded value. All of the code
uses the 0, 16, 32, or 48 adjustment value.
Also remove the decodeZcmpSpimm as its identical to the default
behavior for no custom DecoderMethod.
This correctly rejects imm==0 and prints 1048575 instead of -1.
I've modified the test to only have each hex pattern once with different
check lines before it. This ensures we don't have more invalid messages
printed than we're checking for.
decodeUImmLog2XLenNonZeroOperand already contains the uimm5 check for
RV32 so we can reuse it. This makes C_SLLI_HINT code more similar to the
tblgen code for C_SLLI.
Fixes#133712.
The change causes `c.slli` instructions whose immediate has bit 5 set to
be rejected when disassembling RV32C. Added a test to exhaustively cover
c.slli for 32 bit targets. A minor tweak to make the debug output a
little more readable.
The spec. (20240411) says:
> For RV32C, shamt[5] must be zero; the code points with shamt[5]=1 are
designated for custom extensions. For RV32C and RV64C, the shift amount
must be non-zero; the code points with shamt=0 are HINTs. For all base
ISAs, the code points with rd=x0 are HINTs, except those with shamt[5]=1
in RV32C.
This extension adds two external input output instructions for
non-memory-mapped device.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
Fix for #133446.
According to the RISC-V spec: "C.LUI is valid only when rd≠{x0,x2}, and
when the immediate is not equal to zero. The code points with imm=0 are
reserved".
This change makes the disassembler consider code points with imm=0 as
illegal. It introduces a test which exercises every C.LUI opcode
including the illegal ones but excluding those assigned to C.ADDI16SP).
Output for +c, +c +Zcmop, and +c +no-rvc-hints is checked.
In the `qc.cm.pushfp` instruction, it is like `cm.pushfp` except in one
important way - `qc.cm.pushfp {ra}, -N*16` is not a valid encoding,
because this would update `s0`/`fp`/`x8` without saving it.
This change now correctly rejects this variant of the instruction, both
during parsing and during disassembly. I also implemented validation for
immediates that represent register lists (both kinds), which may help to
catch bugs in the future.
We can name the sub-operands using a DAG in the 'ins'. This allows those
names to be matched to the encoding fields. This removes the need for a
custom encoder/decoder that treats the 2 sub-operands as a single 10-bit
value.
While doing this, I noticed the base and offset names in the
MIOperandInfo were swapped relative to how the operands are parsed and
printed. Assuming that I've correctly understood the parsing/print
format as "offset(base)".
With a minor fix for the build failures.
Original message:
This extension adds nine instructions, eight for non-memory-mapped devices synchronization and delay instruction.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli quic_svs@quicinc.com
This extension adds nine instructions, eight for non-memory-mapped
devices synchronization and delay instruction.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
This extension adds 10 instructions that provide hints to the interface
simulation environment.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/
This patch adds assembler only support.
This extension adds twelve conditional branch instructions that use an
immediate operand for the source.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
Rename RISCV32GPRPair and RISCV32Only_ to RV32Only. This gives a more
natural home for the P extension RV32 conflicts.
While I was there I made some improvements to the debug messages.
The Xqcili extension includes a two instructions that load large
immediates than is available with the base RISC-V ISA.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
This extension adds thirty eight bit manipulation instructions.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.6
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
First thing to know is that the subtarget feature checks used to block
accessing a decoder table are only a performance optimization and not
required for functionality. The tables have their own predicate checks.
I've removed them from all the standard extension tables.
-RV32 Zacas decoder namespace has been renamed to RV32GPRPair, I think
Zilsd(rv32 load/store pair) can go in here too.
-The RV32 Zdinx table has been renamed to also use RV32GPRPair.
-The Zfinx table has been renamed to remove superflous "RV" prefix.
-Zcmp and Zcmt tables have been combined into a ZcOverlap table. I think
Zclsd(rv32 compressed load/store pair) can go in here too.
-All the extra standard extension tables are checked after the main
standard extension table. This makes the common case of the main table
matching occur earlier.
-Zicfiss is the exception to this as it needs to be checked before
the main table since it overrides some encodings from Zcmop. This
can't be handled by a predicate based priority as Zicfiss only overrides
a subset of Zcmop encodings.
Xqccmp is a new spec by Qualcomm that makes a vendor-specific effort to
solve the push/pop + frame pointers issue. Broadly, it takes the Zcmp
instructions and reverse the order they push/pop registers in, which
ends up matching the frame pointer convention.
This extension adds a new instruction not present in Zcmp,
`qc.cm.pushfp`, which will set `fp` to the incoming `sp` value after it
has pushed the registers.
This change duplicates the Zcmp implementation, with minor changes to
mnemonics (for the `qc.` prefix), predicates, and the addition of
`qc.cm.pushfp`. There is also new logic to prevent combining Xqccmp and
Zcmp. Xqccmp is kept separate to Xqci for decoding/encoding etc, as the
specs are separate today.
Specification:
https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0
This implements assembler support for the XRivosVisni custom/vendor
extension from Rivos Inc. which is defined in:
https://github.com/rivosinc/rivos-custom-extensions (See
src/xrivosvisni.adoc)
Codegen support will follow in separate changes.
This makes a single table for vector and another table for system. I
left sf.cease out of system because its not in custom encoding space.
The other system instructions are in the custom part of OPC_SYSTEM.
RISC-V has multiple decoder tables because there is no guarantee that
non-standard extensions do not overlap with each other.
Qualcomm's Xqci family of extensions are intended to be implemented
together, and therefore we want a single decode table for this group of
extensions. This should be more efficient overall, and allows us to use
tablegen's existing mechanism that finds overlapping encodings within
the group.
To implement this, the key addition is `TRY_TO_DECODE_FEATURE_ANY`,
which will use the provided decoder table if any of the features from
the FeatureBitset (first argument) are enabled, rather than if all are
enabled.
We currently have two operands upstream that are an unsigned immediate
with a range constraint - `uimm8ge32` (for `cm.jalt`) and `uimm5gt3`
(for `qc.shladd`).
Both of these were using `decodeUImmOperand<N>` for decoding. For `Zcmt`
this worked, because the generated decoder automatically checked for
`cm.jt` first because the 8 undefined bits in `cm.jalt` are `000?????`
in `cm.jt` (this is to do with the range lower-bound being a
power-of-two). For Zcmt, this patch is NFC.
We have less luck with `Xqciac` - `qc.shladd` is being decoded where the
`uimm5` field is 3 or lower. This patch fixes this by introducing a
`decodeUImmOperandGE<Width, LowerBound>` helper, which will corretly
return `MCDisassembler::Fail` when the immediate is below the lower
bound.
I have added a test to show the encoding where `uimm5` is equal to 3 is
no longer disassembled as `qc.shladd`.
