Tracking Issue for Scalable Vectors (stdarch_aarch64_sve) #145052

This is a tracking issue for the not-yet-accepted RFC for "Scalable Vectors" (rust-lang/rfcs#3838).
The feature gate for the issue is #![feature(stdarch_aarch64_sve)].

This feature is part of the "Scalable Vectors" project goal from 2025h1, 2025h2 and 2026 (rust-lang/goals#270).

About tracking issues

Tracking issues are used to record the overall progress of implementation.

They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Discussion comments will get marked as off-topic or deleted. Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Background and motivation

Quoting from rust-lang/goals#270:

SIMD types and instructions are a crucial element of high-performance Rust applications and allow for operating on multiple values in a single instruction. Many processors have SIMD registers of a known fixed length and provide intrinsics which operate on these registers. Arm's Neon extension is well-supported by Rust and provides 128-bit registers and a wide range of intrinsics.

Instead of releasing more extensions with ever increasing register bit widths, recent versions of AArch64 have a Scalable Vector Extension (SVE), with vector registers whose width depends on the CPU implementation and bit-width-agnostic intrinsics for operating on these registers. By using SVE, code won't need to be re-written using new architecture extensions with larger registers, new types and intrinsics, but instead will work on newer processors with different vector register lengths and performance characteristics.

SVE has interesting and challenging implications for Rust, introducing value types with sizes that can only be known at compilation time, requiring significant work on the language and compiler.

Hardware is generally available with SVE, and key Rust stakeholders want to be able to use these architecture features from Rust. In a recent discussion on SVE, Amanieu, co-lead of the library team, said:

I've talked with several people in Google, Huawei and Microsoft, all of whom have expressed a rather urgent desire for the ability to use SVE intrinsics in Rust code, especially now that SVE hardware is generally available.

While SVE is specifically an AArch64 extension, the infrastructure for scalable vectors in Rust should also enable Rust to support for RISC-V's "V" Vector Extension, and this goal will endeavour to extend Rust in an architecture-agnostic way.

Dependencies

• Tracking Issue for Sized Hierarchy #144404
  • Hierarchy of Sized traits rfcs#3729 extends Rust's concept of sizedness to better support exotically sized types, like scalable vectors. In particular, it introduces the concept of "const sizedness" - whether the size of a type can be determined in a const context. "const sizedness" enables separating the characteristics of Sized types that enable them to implement Copy and act like value types from the characteristics that enable their size to be computed statically at compile-time. Scalable vectors are non-const Sized.

Steps

• Experimentation implementation of rustc_scalable_vector rfcs#3838 in rustc_scalable_vector(N) #143924
  • Experimental implementation will help resolve the unresolved questions in the RFC
• Implement unstable intrinsics in initial SVE intrinsics stdarch#2071
  • As rustc_scalable_vector rfcs#3838 proposes internal infrastructure for defining scalable vector types in the standard library's std::arch, it's hard to evaluate without having some scalable vector types and intrinsics defined
  • We'll update or re-open SVE types and intrinsics stdarch#1509 with these
• Fix follow-ups for initial SVE intrinsics stdarch#2071:
  • Load/store tests are disabled for MSVC because there appeared to be non-deterministic CI failures (Re-enables & Fixes AArch64 SVE ld/st tests for MSVC target stdarch#2142)
  • svpfalse is missing an assert_instr annotation because its current implementation doesn't generate a pfalse (Create a sve_zeroinitializer compiler intrinsic #157110)
  • A handful of intrinsics have no assert_instr on MSVC because they wouldn't disassemble - investigate/report this (see re-enable assert_instr for SVE [us]mull[bt] instructions stdarch#2084)
  • Add support to intrinsic-test for all of the SVE intrinsics (intrinsic-test: sve support  stdarch#2160)
    • Re-enable sveorv testing when LLVM is upgraded (sveorv_s8 intrinsic call optimised out incorrectly llvm/llvm-project#203921 is fixed) - sve: re-enable sveorv testing after LLVM upgrade stdarch#2204
    • Revert codegen_ssa: no dbginfo for scalable vec local w/ -O0 #158088 when LLVM is upgraded (ICE from #dbg_declare of scalable vector alloca on -O0 llvm/llvm-project#204585 is fixed) - Revert "codegen_ssa: no dbginfo for scalable vec local w/ -O0" #160558
    • Enable GCC testing when a new GCC release includes this fix (will be in GCC 17, 16.2, 15.4, 14.5 and 13.5 when released)
  • Investigate whether arm64ec can support SVE
  • Disable SVE intrinsics on big endian (Adds cfg to ensure little endian for SVE stdarch#2145)
• Investigate whether intrinsics that read the FFR should be unsafe because the FFR is caller-saved and could have been clobbered (#t-libs > svrdffr unsafety vibe check)
• Refactor Layout so that scalable vector sizes aren't as easily misused
• Upstream new intrinsics since SVE types and intrinsics stdarch#1509 was originally written
• Investigate and support SVE with inline assembly (Adds support for AArch64 SVE to inline assembly #158312)
• Wait for stabilisation of prerequisites (i.e. Tracking Issue for Sized Hierarchy #144404)
• @RalfJung suggests we have a Miri implementation to ensure we properly understand the opsem aspects of this before stabilization
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• rustc_scalable_vector rfcs#3838 has open questions about how scalable vectors can work when the target_feature must be present for the types to exist
  • This will require experimentation to determine how to resolve
• This would be the first time that we explicitly rely on the post-monomorphization ABI checks that were introduced as a safety net for the "C" ABI. Scalable vectors rely on them even for the "Rust" ABI. The user experience is not great, as usual for post-monomorphization checks: one can see errors from upstream crates by instantiating them with the "wrong" generics. Are we okay with that? All other vector types get passed in-memory for the "Rust" ABI; why is this one treated differently? (The other vector types would also greatly benefit from being passed in-memory.)

Implementation history

• RFC: Add a scalable representation to allow support for scalable vectors rfcs#3268 and Support for a scalable simd representation #118917 were previous attempts at trying to design and implement scalable vectors in Rust
  • This informed our current approach and led to our work on Tracking Issue for Sized Hierarchy #144404
  • SVE types and intrinsics stdarch#1509 similarly is an implementation of SVE types of intrinsics that will be updated
• rustc_scalable_vector(N) #143924
  • This pull request has an initial incomplete implementation of scalable vectors, it needs updating in line with recent revisions to rustc_scalable_vector rfcs#3838 prior to being merged
  • Tracking Issue for Sized Hierarchy #144404 is not yet sufficiently implemented to resolve the sizedness issues with scalable vectors, so this implementation incorrectly makes these vectors Sized temporarily
• various fixes for scalable vectors #153286
• ast_passes: unsupported arch w/ scalable vectors #153608
• scalable vector: type renames and simple checks #153653
• initial SVE intrinsics stdarch#2071
• ast_validation: scalable vectors okay for rustdoc #154850
• library: no cfg(target_arch) on scalable intrinsics #154950
• target: support scalable vectors on arm64ec #154984
• cg_llvm: scalable vectors with simd_cast and simd_select #155106
• cg_ssa: transmute between scalable vectors #155243
• Re-enables & Fixes AArch64 SVE ld/st tests for MSVC target stdarch#2142
• Adds cfg to ensure little endian for SVE stdarch#2145
• Create a sve_zeroinitializer compiler intrinsic #157110
• codegen_ssa: peel trans. wrappers on scalable vecs #157768
• scalable vecs size incl. num vecs + no sret for scalable vecs #157915
• intrinsic-test: sve support  stdarch#2160
  • intrinsic-test: sve type parsing and constraints stdarch#2121
  • intrinsic-test: run rustfmt on generated sources stdarch#2122
  • intrinsic-test: add lots of documentation stdarch#2124
  • intrinsic-test: refactor populate_random and related code stdarch#2126
  • intrinsic-test: remove arm::argument module stdarch#2127
  • update arm_intrinsics.json for svset and svget stdarch#2162
  • core_arch: redefine svrev, svzip and svuzp stdarch#2163
  • intrinsic-test: fwd args in intrinsic-test.sh stdarch#2164
  • intrinsic-test: add filters for sve stdarch#2169
  • intrinsic-test: make types generic over SupportedArchitecture stdarch#2170
  • intrinsic-test: remove concatln! and redundant newlines stdarch#2171
  • intrinsic-test: simplify architecture constants stdarch#2172
  • intrinsic-test: simplify type printing + comparison abstraction stdarch#2173
• Adds support for AArch64 SVE to inline assembly #158312
• codegen_ssa: no dbginfo for scalable vec local w/ -O0 #158088
• codegen_ssa: multiply scalable vec size by vscale #158253
• Revert "codegen_ssa: no dbginfo for scalable vec local w/ -O0" #160558
• sve: re-enable sveorv testing after LLVM upgrade stdarch#2204
• mir: prohibit projection into scalable vec #160642
• passes: rustc_scalable_vector fields are not dead #161231