aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/RISCV/Disassembler
AgeCommit message (Collapse)AuthorFilesLines
2026-01-25[RISCV] Use decodeVMaskReg for VMaskCarryInOp. NFC (#177742)Craig Topper1-10/+0
After #177678 we don't need DecodeVMV0RegisterClass to reject vm=1 cases. All instructions that use VMaskCarryInOp have set vm=0 in their tablegen classes.
2026-01-24[RISCV] Remove decodeRTZArg. NFC (#177744)Craig Topper1-10/+0
We can set the frm field in tablegen class which makes the disassembler only accept that fixed value without needing to reject it with decodeRTZArg.
2026-01-23[RISCV] Add a template function for disassembling LMUL=2/4/8 vector ↵Craig Topper1-39/+6
registers. NFC (#177681)
2026-01-23[RISCV] Use DecodeSimpleRegisterClass in 2 more cases. NFC (#177680)Craig Topper1-22/+0
2026-01-22[RISCV] Use DecoderMethod and a template function to reduce the amount of ↵Craig Topper1-128/+8
boilerplate for decodings a register class. NFC (#177296) The decode functions for GPR/FPR and their compressed register classes are very similar. We just need the number of registers, the constant for the first register in the class, and whether or not the register class is shrunk by RVE. I've added a template function that takes this information and used the DecoderMethod in tablegen to provide the values for the the template parameters. I kept an alias for DecodeGPRRegisterClass because it has multiple callers. --------- Co-authored-by: Sam Elliott <sam@lenary.co.uk>
2026-01-13[RISCV] AI Foundry ET extensions for RISC-V (#174571)Abel Bernabeu1-0/+25
This patch is part of an ongoing effort for upstreaming the AI Foundry ET extensions for RISC-V, formerly known as the ET-SoC-1 Minion extensions by Esperanto Technologies. Changes ======= The changes in this patch are: - Defining the XAIFET feature as an "umbrella" extension under which all the vendor extensions from ET-SoC-1 are included. - Defining Esperanto Technologies's ET-SoC-1 Minion processor (et-soc1). - Defining Ainekko's Erbium Minion processor (an-erbium), using the same ISA. - Adding the XAIFET vector register and mask register classes. - Adding all the custsom machine instructions Reference manual ================ Full documentation for these extensions is publicly available at the following URL: https://github.com/aifoundry-org/et-man/blob/main/ET%20Programmer's%20Reference%20Manual.pdf Note on gather/scatter syntax ============================= The assembly syntax for gather/scatter instructions used by Esperanto Technologies used a complex source operand consisting on two registers. For example, consider the syntax that the manual proposed for `fg32w.ps`: fg32w.ps fd, fs1(rs1) Note that the second operand (the source) is composed of two register names. While Esperanto Technologies fork of LLVM 11 supported this syntax, it is easier to fit on the existing RISCV infrastructure if a comma is inserted between the two source register names: fg32w.ps fd, fs1, (rs1) That way is as clear as the proposal from the manual and does not require defining a complex operand consisting on two registers. This subject was discussed on the #et-platform Discord channel, with enough agreement on streamlining the syntax as proposed here for llvm/clang. Note on instruction prefixes ============================ The `aif.` prefix has been added to all the instructions under these extensions, in line with the RISC-V toolchain practices, so an instruction from the manual like `fadd.pi` becomes `aif.fadd.pi` with the upstream toolchain. The same goes for CSRs, so `fcc` becomes `aif.fcc`. Authors ======= This patch contains code rebased from the LLVM 11 fork by Esperanto Technologies as published at the following URL: https://github.com/aifoundry-org/llvm/tree/et The list of authors that contributed to that fork follow: - Abel Bernabeu <abel.bernabeu@esperantotech.com>, maintainer. - David Callahan <callahan@reservoir.com>, project founder. - Josep M. Perez <josep.m.perez@esperantotech.com>, contributor. - Muhammad Kamran <muhammad.kamran@esperantotech.com>, contributor. - Pere Munt <pere.munt@esperantotech.com>, contributor. - Rafael Jimenez <rafael.jimenez@esperantotech.com>, contributor. - Stefan Freudenberger <stefan@reservoir.com>, contributor.
2026-01-09[RISCV] Try to disassemble 48-bit and larger instructions as 32-bit ↵Craig Topper1-6/+12
instructions first. (#175122) The encoding scheme for 48-bit and larger instructions has not been ratified yet. The RISC-V ISA manual previously included a proposal that included 4 reserved major opcodes. LLVM's disassembler implements this proposal as does binutils. A vendor extension might have used the reserved opcodes, as a non-conforming 32-bit extension. Try to decode as a 32-bit instruction first to catch these cases. Should help with #174571.
2025-10-21[RISCV][MC] Introduce XSfvfexp* and XSfvfbfexpa* extensions and their MC ↵Min-Yih Hsu1-1/+4
supports (#164349) XSfvfbfexp16e, XSfvfexp16e, and XSfvfexp32e are SiFive's vector exponential instruction extensions of BFloat16, F16, and F32, respectively. Spec: https://www.sifive.com/document-file/exponential-function-instruction-xsfvfexp32e-xsfvf XSfvfexpa and XSfvfexpa64e are SiFive's vector exponential approximation instruction extensions where the former supports F16 and F32 and the latter covers F64. These instructions approximate 2 raised to a fractional power. Spec: https://www.sifive.com/document-file/exponential-approximation-instruction-xsfvfexpa-ex This patch adds their corresponding features and MC supports. --------- Co-authored-by: Jesse Huang <jesse.huang@sifive.com> Co-authored-by: Craig Topper <craig.topper@sifive.com>
2025-09-23[RISCV] Add MC layer support for Andes XAndesVSIntH extension. (#159514)Rux1241-2/+2
Add MC layer support for Andes XAndesVSIntH extension. The spec is available at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release
2025-09-22[TableGen][DecoderEmitter][RISCV] Always handle `bits<0>` (#159951)Sergei Barannikov1-0/+8
Previously, `bits<0>` only had effect if `ignore-non-decodable-operands` wasn't specified. Handle it even if the option was specified. This should allow for a smoother transition to the option removed. The change revealed a couple of inaccuracies in RISCV compressed instruction definitions. * `C_ADDI4SPN` has `bits<5> rs1` field, but `rs1` is not encoded. It should be `bits<0>`. * `C_ADDI16SP` has `bits<5> rd` in the base class, but it is unused since `Inst{11-7}` is overwritten with constant bits. We should instead set `rd = 2` and `Inst{11-7} = rd`. There are a couple of alternative fixes, but this one is the shortest.
2025-09-15[RISCV] Remove a couple of custom instruction decoders (NFC) (#158483)Sergei Barannikov1-40/+24
These instructions can be decoded automatically.
2025-09-12[RISCV][MC] Add MC support of Zibi experimental extension (#127463)Boyao Wang1-0/+8
This adds the MC support of Zibi v0.1 experimental extension. References: * https://lf-riscv.atlassian.net/wiki/spaces/USXX/pages/599261201/Branch+with+Immediate+Zibi+Ratification+Plan * https://lf-riscv.atlassian.net/browse/RVS-3828 * https://github.com/riscv/zibi/releases/tag/v0.1.0
2025-09-11[RISCV] Fix GPRPairNoX0 Disassembly (#158001)Sam Elliott1-0/+9
Both GPRPair and GPRPairNoX0 were using the same decoder before this change, which meant that GPRPairNoX0 would disassemble zeroes to the `X0_Pair`. This ensures the NoX0 decoder correctly fails to decode zeroes.
2025-09-04[RISCV] Remove post-decoding instruction adjustments (#156360)Sergei Barannikov1-17/+8
Some instructions implicitly define/use X2 (SP) register, but instead of being present in the Defs/Uses lists, it is sometimes modeled as an explicit operand with SP register class. Since the operand is not encoded into the instruction, it cannot be disassembled, and we have `RISCVDisassembler::addSPOperands()` that addresses the issue by mutating the (incompletely) decoded instruction. This change makes the operand decodable by adding `bits<0>` field for that operand to relevant instruction encodings and removes `RISCVDisassembler::addSPOperands()`.
2025-09-02[MC][DecoderEmitter] Fix build warning: explicit specialization cannot have ↵Rahul Joshi1-3/+5
a storage class (#156375) 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.
2025-09-01[AMDGPU, RISCV] Fix warningsKazu Hirata1-3/+3
This patch fixes: llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp:451:13: error: explicit specialization cannot have a storage class [-Werror,-Wexplicit-specialization-storage-class] llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp:452:13: error: explicit specialization cannot have a storage class [-Werror,-Wexplicit-specialization-storage-class] llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp:454:1: error: explicit specialization cannot have a storage class [-Werror,-Wexplicit-specialization-storage-class] llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp:456:1: error: explicit specialization cannot have a storage class [-Werror,-Wexplicit-specialization-storage-class] While I am at it, this patch changes the storage types of InsnBitWidth specilization to "inline constexpr" to avoid linker errors.
2025-09-01[RISCV] Fix -Wexplicit-specialization-storage-class warningsFangrui Song1-3/+3
2025-09-01[LLVM][MC][DecoderEmitter] Add support to specialize decoder per bitwidth ↵Rahul Joshi1-7/+9
(#154865) 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 ```
2025-09-01[RISC-V] Added the mips extension instructions like ehb,ihb and pause etc ↵UmeshKalappa1-7/+8
for MIPS RV64 P8700. (#155747) Please refer the https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf for more information . and files like RISCVInstrInfoXMips.td clang formatted . No Regression found. --------- Co-authored-by: Craig Topper <craig.topper@sifive.com>
2025-08-22[NFC][MC][RISCV] Rearrange decoder functions for RISCV disassembler (#154998)Rahul Joshi1-10/+2
Rearrange decode functions to be before including the generated disassembler code and eliminate forward declarations for most of them. This is possible because `fieldFromInstruction` is now in MCDecoder.h and not in the generated disassembler code.
2025-08-22[RISCV] Add initial assembler/MC layer support for big-endian (#146534)Djordje Todorovic1-0/+4
This patch adds basic assembler and MC layer infrastructure for RISC-V big-endian targets (riscv32be/riscv64be): - Register big-endian targets in RISCVTargetMachine - Add big-endian data layout strings - Implement endianness-aware fixup application in assembler backend - Add byte swapping for data fixups on BE cores - Update MC layer components (AsmInfo, MCTargetDesc, Disassembler, AsmParser) This provides the foundation for BE support but does not yet include: - Codegen patterns for BE - Load/store instruction handling - BE-specific subtarget features
2025-08-21[NFC][MC][Decoder] Extract fixed pieces of decoder code into new header file ↵Rahul Joshi1-0/+2
(#154802) Extract fixed functions generated by decoder emitter into a new MCDecoder.h header.
2025-08-18[RISCV] Add SpacemiT XSMTVDot (SpacemiT Vector Dot Product) extension. (#151706)林克1-0/+3
The full spec can be found at spacemit-x60 processor support scope: Section 2.1.2.2 (Features): https://developer.spacemit.com/documentation?token=BWbGwbx7liGW21kq9lucSA6Vnpb#2.1 This patch only supports assembler.
2025-08-08[RISCV] Move the decoder table for XCV, Xqci and XRivos from standard ↵Jim Lin1-3/+3
section to vendor section. NFC
2025-07-28[RISCV] Move definitions of decodeZcmpRlist/decodeXqccmpRlistS0 to their ↵Craig Topper1-23/+15
declarations. NFC These don't need anything from RISCVDisassemblerTables.inc so we can define them earlier.
2025-07-25[RISCV] Merge some of the C_*_HINT instruction into the regular C_* ↵Craig Topper1-105/+6
instructions. (#150710) 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.
2025-07-15[RISCV] Add Andes XAndesBFHCvt (Andes Scalar BFLOAT16) extension (#148563)Jim Lin1-1/+2
The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. The extension includes only two instructions: one for converting from f32 to f16, and another for converting from f16 to f32. This patch only implements MC support for XAndesBFHCvt.
2025-07-07[RISCV] Add Andes XAndesVSIntLoad (Andes Vector INT4 Load) extension (#147005)Jim Lin1-1/+2
The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. This patch only implements MC support for XAndesVSIntLoad. --------- Co-authored-by: Lino Hsing-Yu Peng <linopeng@andestech.com>
2025-07-03[RISCV] Added the MIPS prefetch extensions for MIPS RV64 P8700. (#145647)UmeshKalappa1-0/+3
the extension enabled with xmipscbop. Please refer "MIPS RV64 P8700/P8700-F Multiprocessing System Programmer’s Guide" for more info on the extension at https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf
2025-07-01[RISCV] Use uint64_t for Insn in getInstruction32 and getInstruction16. NFC ↵Craig Topper1-2/+6
(#146619) 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.
2025-06-18[RISCV] Add Andes XAndesVBFHCvt (Andes Vector BFLOAT16 Conversion) extension ↵Jim Lin1-2/+2
(#144320) The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. This patch only supports assembler. The instructions are similar to `Zvfbfmin` and the only difference with `Zvfbfmin` is that `XAndesVBFHCvt` doesn't have mask variant.
2025-06-17[llvm] annotate interfaces in llvm/Target for DLL export (#143615)Andrew Rogers1-1/+3
## 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
2025-05-21[RISCV] Add MC layer support for XSfmm*. (#133031)Craig Topper1-3/+36
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>
2025-05-15[RISCV][MC] Add support for Q extension (#139369)Iris Shi1-0/+11
Closes #130217. https://github.com/riscv/riscv-isa-manual/blob/main/src/q-st-ext.adoc
2025-05-15[RISCV] Add Andes XAndesVDot (Andes Vector Dot Product) extension. (#139849)Jim Lin1-1/+2
The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. This patch only supports assembler. Intrinsics support will be added in a later patch.
2025-05-12[RISCV] Add Andes XAndesVPackFPH (Andes Vector Packed FP16) extension. (#138827)Jim Lin1-1/+2
The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. This patch only supports assembler. Intrinsics support will be added in a later patch.
2025-04-28[RISCV] Add Andes XAndesperf (Andes Performance) extension. (#135110)Jim Lin1-6/+9
The spec can be found at: https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release. This patch only supports assembler. Relocation and fixup for the branch and gp-implied instructions will be added in a later patch.
2025-04-15[RISCV] Fix xmipscmov extension name (#135647)Djordje Todorovic1-2/+2
The right name was used in riscv-toolchain-conventions docs.
2025-04-04[RISCV] Make decodeXqccmpRlistS0 defer to decodeZcmpRlist after checking for ↵Craig Topper1-4/+2
S0 being included. NFC This reduces code duplication.
2025-04-04[RISCV] Remove unused function declaration. NFCCraig Topper1-3/+0
2025-04-04[RISCV] Rename Spimm to StackAdj in most places. NFCCraig Topper1-8/+2
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.
2025-04-02[RISCV] Modify register type of extd* Xqcibm instructions (#134027)Sudharsan Veeravalli1-0/+10
The v0.8 spec specifies that rs1 cannot be x31 (t6) since these instructions operate on a pair of registers (rs1 and rs1 + 1) with no wrap around. The latest spec can be found here: https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.8.0
2025-03-31[RISCV] Use decodeCLUIImmOperand when disassembling C_LUI_HINT. (#133789)Craig Topper1-8/+21
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.
2025-03-31[RISCV] Correct disassembly of cm.push/pop for RVE. (#133816)Craig Topper1-6/+12
We shouldn't disassemble any encoding that refers to registers x16-x31 with RV32E.
2025-03-31[RISCV] Prevent disassembling RVC hint instructions with x16-x31 for RVE. ↵Craig Topper1-14/+24
(#133805) We can't ignore the return value form the GPR decode function, as it contains the RVE check.
2025-03-31[RISCV] Use decodeUImmLog2XLenNonZeroOperand in decodeRVCInstrRdRs1UImm. NFC ↵Craig Topper1-15/+11
(#133759) 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.
2025-03-31[RISCV] For RV32C, disassembly of c.slli should fail when immediate > 31 ↵Paul Bowen-Huggett1-4/+8
(#133713) 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.
2025-03-28[RISCV] Add Qualcomm uC Xqciio (External Input Output) extension (#132721)quic_hchandel1-9/+9
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>
2025-03-28[RISCV] Remove unnecessary if guard before calling SignExtend64<6> in ↵Craig Topper1-2/+1
decodeCLUIImmOperand. NFC (#133514)
2025-03-28[RISCV] Fix the disassembler's handling of C.LUI when imm=0 (#133450)Paul Bowen-Huggett1-2/+3
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.
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-20 10:07:06 +0000