Stabilizing SIMD-aligned types ahead of the rest of SIMD



I am aware of and its RFC. Also see and

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 is resolved.

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

1 Like

What's the next step towards the stabilization of SIMD?

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

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

struct Simd4<T>(T, T, T, T);

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



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.


closed #4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.