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.
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>
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.
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.
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>
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.
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.
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
```
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.
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
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.
