Now that the target_feature
RFC has some consensus it is time to discuss the next step towards SIMD on stable Rust.
From the discussions in the target_feature
RFC it seems clear that the next step is having an RFC about SIMD types. This summarizes the current state of affairs:
-
Background:
- RFC 1199: SIMD groundwork (merged), (pre-RFC discussion).
- RFC 2045: target_feature (FCP) (please defer any discussion of this RFC to its PR in the github repo), (pre-RFC discussion).
- Stabilizing SIMD-aligned types ahead of the rest of SIMD.
- Getting explicit SIMD on stable Rust.
-
Implementation status: The feature
repr(simd)
is currently implemented, its semantics are not sufficiently specified in any RFC, and some ABI issues must be resolved, but it can be used on nightly today to write SIMD types “just fine”. -
Consensus from previous discussions: @burntsushi achieved consensus on trying to stabilize concrete SIMD types like
f32x4
without stabilizingrepr(simd)
. However, during thetarget_feature
RFC some ABI issues where discovered, and resolving them is going to require a more detailed specification ofrepr(simd)
. Also, @nrc raised the question of whether we shouldn’t be using#[repr(simd)] [T; N]
on arrays instead of tuple structs. Since the type-level const RFC is (almost) merged we might want to reconsider this.
Anyhow, the purpose of this post is not to discuss the details of SIMD types, but to gather consensus on what is the next step. I think we have two main choices:
- have an RFC for the concrete SIMD types that we want to stabilize and their semantics, or
- have an RFC to specify
repr(simd)
first, and then decide whether we want to stabilizerepr(simd)
or only some SIMD types after that discussion is over.
I think that any discussion on the semantics of SIMD types is going to implicitly touch repr(simd)
, so I find the second alternative, specifying repr(simd)
, less messy. After that is done, an RFC for concrete SIMD types will be trivial to write anyway.
Thoughts?