Tracking Issue for Scalable Vectors (`stdarch_aarch64_sve`)

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/rust-project-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/rust-project-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

• #144404
  • rust-lang/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 rust-lang/rfcs#3838 in #143924
  • Experimental implementation will help resolve the unresolved questions in the RFC
• Implement unstable intrinsics in rust-lang/stdarch#2071
  • As rust-lang/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 rust-lang/stdarch#1509 with these
• Fix follow-ups for rust-lang/stdarch#2071:
  • Load/store tests are disabled for MSVC because there appeared to be non-deterministic CI failures (rust-lang/stdarch#2142)
  • svpfalse is missing an assert_instr annotation because its current implementation doesn't generate a pfalse (rust-lang/rust#157110)
  • A handful of intrinsics have no assert_instr on MSVC because they wouldn't disassemble - investigate/report this (see rust-lang/stdarch#2084)
  • Add support to intrinsic-test for all of the SVE intrinsics (rust-lang/stdarch#2160)
    • Re-enable sveorv testing when LLVM is upgraded (llvm/llvm-project#203921 is fixed) - rust-lang/stdarch#2204
    • Revert rust-lang/rust#158088 when LLVM is upgraded (llvm/llvm-project#204585 is fixed) - rust-lang/rust#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 (rust-lang/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 rust-lang/stdarch#1509 was originally written
• Investigate and support SVE with inline assembly (rust-lang/rust#158312)
• Wait for stabilisation of prerequisites (i.e. #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

• rust-lang/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

• rust-lang/rfcs#3268 and #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 #144404
  • rust-lang/stdarch#1509 similarly is an implementation of SVE types of intrinsics that will be updated
• rust-lang/rust#143924
  • This pull request has an initial incomplete implementation of scalable vectors, it needs updating in line with recent revisions to rust-lang/rfcs#3838 prior to being merged
  • #144404 is not yet sufficiently implemented to resolve the sizedness issues with scalable vectors, so this implementation incorrectly makes these vectors Sized temporarily
• rust-lang/rust#153286
• rust-lang/rust#153608
• rust-lang/rust#153653
• rust-lang/stdarch#2071
• rust-lang/rust#154850
• rust-lang/rust#154950
• rust-lang/rust#154984
• rust-lang/rust#155106
• rust-lang/rust#155243
• rust-lang/stdarch#2142
• rust-lang/stdarch#2145
• rust-lang/rust#157110
• rust-lang/rust#157768
• rust-lang/rust#157915
• rust-lang/stdarch#2160
  • rust-lang/stdarch#2121
  • rust-lang/stdarch#2122
  • rust-lang/stdarch#2124
  • rust-lang/stdarch#2126
  • rust-lang/stdarch#2127
  • rust-lang/stdarch#2162
  • rust-lang/stdarch#2163
  • rust-lang/stdarch#2164
  • rust-lang/stdarch#2169
  • rust-lang/stdarch#2170
  • rust-lang/stdarch#2171
  • rust-lang/stdarch#2172
  • rust-lang/stdarch#2173
• rust-lang/rust#158088
• rust-lang/rust#158253
• rust-lang/rust#160558
• rust-lang/stdarch#2204
• rust-lang/rust#160642
• rust-lang/rust#161231