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>
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
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.
These instructions can be decoded automatically.
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
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.
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()`.
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 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.