Skip to content

Commit bf4ae18

Browse files
nikomatsakisnikomatsakis
authored
Merge pull request #152 from davidtwco/sve-sme-goal
Propose SVE/SME support as a 2025H1 goal
2 parents 29a97da + ad7c1a0 commit bf4ae18

File tree

1 file changed

+170
-0
lines changed

1 file changed

+170
-0
lines changed

‎src/2025h1/arm-sve-sme.md

Lines changed: 170 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,170 @@
1+
# SVE and SME on AArch64
2+
3+
| Metadata | |
4+
| -------- | --------------------------- |
5+
| Owner(s) | Rust team at Arm |
6+
| Teams | [lang], [types], [compiler] |
7+
| Status | Proposed |
8+
9+
*Arm's Rust team is @davidtwco, @adamgemmell, @jacobbramley, @JamieCunliffe and @Jamesbarford, as
10+
well as @mrkajetanp and @harmou01 as graduates on rotation. This goal will be primarily worked on
11+
by @davidtwco and @JamieCunliffe.*
12+
13+
## Summary
14+
15+
Over the next six months, we will aim to merge nightly support for SVE and establish a path
16+
towards stabilisation:
17+
18+
- propose language changes which will enable scalable vector types to be represented in Rust's
19+
type system
20+
- land an experimental nightly implementation of SVE
21+
- identify remaining blockers for SVE stabilisation and plan their resolution
22+
- gain a better understanding of SME's implications for Rust and identify first steps towards design
23+
and implementation
24+
25+
## Motivation
26+
27+
AArch64 is an important architecture for Rust, with two tier 1 targets and over thirty targets in
28+
lower tiers. It is widely used by some of Rust's largest stakeholders and as a systems language, it
29+
is important that Rust is able to leverage all of the hardware capabilities provided by the
30+
architecture, including new SIMD extensions: SVE and SME.
31+
32+
### The status quo
33+
34+
SIMD types and instructions are a crucial element of high-performance Rust applications and allow
35+
for operating on multiple values in a single instruction. Many processors have SIMD registers of a
36+
known fixed length and provide intrinsics which operate on these registers. Arm's Neon extension
37+
is well-supported by Rust and provides 128-bit registers and a wide range of intrinsics.
38+
39+
Instead of releasing more extensions with ever increasing register bit widths, recent versions of
40+
AArch64 have a Scalable Vector Extension (SVE), with vector registers whose width depends on the CPU
41+
implementation and bit-width-agnostic intrinsics for operating on these registers. By using SVE,
42+
code won't need to be re-written using new architecture extensions with larger registers, new types
43+
and intrinsics, but instead will work on newer processors with different vector register lengths
44+
and performance characteristics.
45+
46+
SVE has interesting and challenging implications for Rust, introducing value types with sizes that
47+
can only be known at compilation time, requiring significant work on the language and compiler.
48+
Arm has since introduced Scalable Matrix Extensions (SME), building on SVE to add new capabilities
49+
to efficiently process matrices, with even more interesting implications for Rust.
50+
51+
Hardware is generally available with SVE, and key Rust stakeholders want to be able to use these
52+
architecture features from Rust. In a recent discussion on SVE, [Amanieu, co-lead of the
53+
library team, said][quote_amanieu]:
54+
55+
> I've talked with several people in Google, Huawei and Microsoft, all of whom have expressed a
56+
> rather urgent desire for the ability to use SVE intrinsics in Rust code, especially now that SVE
57+
> hardware is generally available.
58+
59+
While SVE is specifically an AArch64 extension, the infrastructure for scalable vectors in Rust
60+
should also enable Rust to support for RISC-V's "V" Vector Extension, and this goal will endeavour
61+
to extend Rust in an architecture-agnostic way. SVE is supported in C through Arm's C Language
62+
Extensions (ACLE) but requires a change to the C standard (documented in [pages 122-126 of the
63+
2024Q3 ACLE][acle_sve]), so Rust has an opportunity to be the first systems programming language
64+
with native support for these hardware capabilities.
65+
66+
SVE is currently entirely unsupported by Rust. There is [a long-standing RFC][rfc_sve] for the
67+
feature which proposes special-casing SVE types in the type system, and [a experimental
68+
implementation][impl_sve] on this RFC. While these efforts have been very valuable in understanding
69+
the challenges involved in implementing SVE in Rust, and providing an experimental forever-unstable
70+
implementation, they will not be able to be stabilised as-is.
71+
72+
This goal's owners have an nearly-complete RFC proposing language changes which will allow scalable
73+
vectors to fit into Rust's type system - this pre-RFC has been informally discussed with members of
74+
the language and compiler teams and will be submitted alongside this project goal.
75+
76+
[acle_sve]: https://github.com/ARM-software/acle/releases/download/r2024Q3/acle-2024Q3.pdf
77+
[quote_amanieu]: https://github.com/rust-lang/rust/pull/118917#issuecomment-2202256754
78+
[rfc_sve]: https://github.com/rust-lang/rust/pull/118917
79+
[impl_sve]: https://github.com/rust-lang/rfcs/pull/3268
80+
81+
### The next 6 months
82+
83+
The primary objective of this initial goal is to land a nightly experiment with SVE and
84+
establish a path towards stabilisation:
85+
86+
- Landing a nightly experiment is nearing completion, having been in progress for some time. Final
87+
review comments are being addressed and both [RFC][rfc_sve] and [implementation][impl_sve] will
88+
be updated shortly.
89+
- A comprehensive RFC proposing extensions to the type system will be opened alongside this goal.
90+
It will primarily focus on extending the `Sized` trait so that SVE types, which are value types
91+
with a static size known at runtime, but unknown at compilation time, can implement `Copy`
92+
despite not implementing `Sized`.
93+
94+
### The "shiny future" we are working towards
95+
96+
Adding support for Scalable Matrix Extensions in Rust is the next logical step following SVE
97+
support. There are still many unknowns regarding what this will involve and part of this goal or the
98+
next goal will be understanding these unknowns better.
99+
100+
## Design axioms
101+
102+
- **Avoid overfitting.** It's important that whatever extensions to Rust's type system are proposed
103+
are not narrowly tailored to support for SVE/SME, can be used to support similar extensions
104+
from other architectures, and unblocks or enables other desired Rust features wherever possible
105+
and practical.
106+
- **Low-level control.** Rust should be able to leverage the full capabilities and performance of
107+
the underlying hardware features and should strive to avoid inherent limitations in its support.
108+
- **Rusty-ness.** Extensions to Rust to support these hardware capabilities should align with
109+
Rust's design axioms and feel like natural extensions of the type system.
110+
111+
## Ownership and team asks
112+
113+
Here is a detailed list of the work to be done and who is expected to do it. This table includes
114+
the work to be done by owners and the work to be done by Rust teams (subject to approval by the
115+
team in an RFC/FCP).
116+
117+
| Subgoal | Owner(s) or team(s) | Notes |
118+
| ------------------------------------------------- | ------------------------------------| ----- |
119+
| Discussions and moral support | ![Team] [lang], [types], [compiler] |
120+
| Land nightly experiment for SVE types | @JamieCunliffe |
121+
| ↳ Author RFC | | Update [rfcs#3268][rfc_sve], will still rely on exceptions in the type system
122+
| ↳ RFC decision | ![Team] [lang], [types] |
123+
| ↳ Implementation | | Update [rust#118917][impl_sve]
124+
| ↳ Standard reviews | ![Team] [compiler] |
125+
| Upstream SVE types and intrinsics | @JamieCunliffe | Using `repr(scalable)` from previous work, upstream the nightly intrinsics and types
126+
| Extending type system to support scalable vectors | @davidtwco |
127+
| ↳ Author RFC | |
128+
| ↳ RFC decision | ![Team] [lang], [types] |
129+
| ↳ Implementation | |
130+
| ↳ Standard reviews | ![Team] [compiler] |
131+
| Stabilize SVE types | @JamieCunliffe, @davidtwco |
132+
| ↳ Implementation | @JamieCunliffe | Update existing implementation to use new type system features
133+
| ↳ Stabilisations | ![Team] [lang] |
134+
| ↳ Blog post announcing feature | @davidtwco |
135+
| Investigate SME support | @JamieCunliffe, @davidtwco |
136+
| ↳ Discussions and moral support | ![Team] [lang], [types], [compiler] |
137+
| ↳ Draft next goal | @davidtwco |
138+
139+
### Definitions
140+
141+
Definitions for terms used above:
142+
143+
* *Discussion and moral support* is the lowest level offering, basically committing the team to
144+
nothing but good vibes and general support for this endeavor.
145+
* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
146+
* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback
147+
(no decision expected).
148+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
149+
* *Org decisions* means reaching a decision on an organizational or policy matter.
150+
* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should
151+
be expected to briefly review.
152+
* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
153+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected
154+
to be unduly large or complicated.
155+
* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the
156+
expectation that there will be *some* response from the next weekly triage meeting.
157+
* *Dedicated review* means identifying an individual (or group of individuals) who will review the
158+
changes, as they're expected to require significant context.
159+
* Other kinds of decisions:
160+
* [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to
161+
add nightly features that do not yet have an RFC. They are limited to trusted contributors and
162+
are used to resolve design details such that an RFC can be written.
163+
* Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used
164+
to propose a 'larger than average' change and get feedback from the compiler team.
165+
* Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html)
166+
describes a change to the standard library.
167+
168+
## Frequently asked questions
169+
170+
None yet.

0 commit comments

Comments
 (0)