[LFI][AArch64] Support for SVE/SVE2 and SME/SME2
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
The AArch64 LFI target currently supports the Armv8.1-A instruction subset. This issue tracks extending LFI sandboxing to SVE, SVE2, SME, and SME2. There are two components: (1) expanding the rewriter's instruction metadata to cover the new memory instructions, and (2) handling SVE gather/scatter, which does not fit the existing sandboxing model.
The LFI rewriter is implemented in `llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCLFIRewriter.cpp`, with per-opcode metadata in `llvm/lib/Target/AArch64/AArch64LFI.td`. Its core operation is masking a single scalar base register into the sandbox with `add x28, x27, wM, uxtw`.
#### Component 1: metadata for the new instructions
Nearly all SVE and SME memory instructions use a single scalar base register (`[Xn{, #imm, MUL VL}]` or `[Xn, Xm, LSL #n]`) and fit the existing model. This includes all of SME/SME2 (there is no gather/scatter in SME) and most instruction forms in SVE/SVE2. Supporting them is mostly a matter of adding metadata that records each opcode's base/offset operand positions.
This can be done with the current metadata approach, or with one of the more general approaches prototyped in these experimental PRs:
- https://github.com/lfi-project/llvm-project/pull/5: explicit centralized lookup tables (more similar to what we have currently).
- https://github.com/lfi-project/llvm-project/pull/6: derive the addressing mode and base-register mapping automatically from the instruction records, reducing the manual per-instruction work.
Since the SVE/SME instruction sets are large, it may be useful to decide to refactor the metadata approach as part of this work.
#### Component 2: scatter/gather via runtime calls
SVE/SVE2 gather loads and scatter stores cannot use the base-masking scheme, because there is no single scalar base register to mask. The address of each lane comes from a vector register, for which we do not have a reserved register and masking sequence to apply efficiently.
These should be handled by rewriting the instruction to a runtime call: hand the vector of addresses to an LFI runtime helper that validates or masks each lane and performs the accesses. This needs an ABI for passing the address vector and predicate to the helper, and would need an implementation of the helper in the runtime, located at https://github.com/lfi-project/lfi-runtime.
Contributor guide
Research direction
Start by reading llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCLFIRewriter.cpp and the opcode metadata in llvm/lib/Target/AArch64/AArch64LFI.td, then compare the approaches in experimental PRs 5 and 6. Define coverage for SVE, SVE2, SME, and SME2 metadata, and investigate the lfi-runtime repository for the ABI and helper needed for gather/scatter. Done means scalar-base forms are sandboxed and vector-address forms are handled through the agreed runtime interface.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100