Stabilizing SIMD-aligned types ahead of the rest of SIMD

[briansmith]

Hi,

I am aware of https://github.com/rust-lang/rust/pull/27169 and its RFC. Also see https://github.com/rust-lang/rust/issues/4578 and https://github.com/rust-lang/rfcs/issues/325.

The SIMD RFC nicely split the feature into three parts: types, operations, and feature detection. IIUC, the type types part is already implemented but using them results in “error: SIMD types are experimental and possibly buggy (see issue #27731)”.

In my crypto work, I already have SIMD-optimized implementations of basically every mainstream crypto primitive on every mainstream platform, written in external assembly language files (.s/.asm files). However, I don’t have a convenient and safe way of using all of them from Rust because Rust doesn’t provide a way of declaring struct members that are aligned to the platform’s SIMD requirements, and some of the functions require SIMD alignment.

It seems like it would be a while before all of the SIMD groundwork feature can be stabilized. However, it seems like #repr(simd) is in good enough shape to stabilize, especially after https://github.com/rust-lang/rust/issues/26403 is resolved.

Would anybody object to an RFC that split out #[repr(simd)] from the rest for stabilization?

[alexcrichton]

cc @huon (author of the simd crate and the original RFC)

I believe the major “contentious point” around #[repr(simd)] was something like:

#[repr(simd)]
struct Simd4<T>(T, T, T, T);

It seems fine to push towards stabilizing the non-generic usage, however, to me at least.

[huon]

Yeah, as @alexcrichton says, it is only the generic types that are questionable, so an RFC to stabilise non-generic repr(simd) seems fine to me too.