What to do about repr(C, simd)?

[hanna-kruppe]

Currently, repr(C, simd) warns about "incompatible representation hints", but leaving off the repr(C) triggers the FFI lint when the SIMD type is used in FFI.

Note that #[repr(C)] #[repr(simd)] does not warn only due to #47094. Most uses of SIMD in FFI this in the Rust source tree use two separate repr attributes, which is why they didn't trigger this warning so far.

There's two ways to resolve this:

1. Require repr(C, simd) for SIMD types used in FFI.
2. Say repr(simd) is sufficient for FFI (in principle -- there are other concerns that keep SIMD-FFI feature gated at the moment) and keep the warning about repr(C, simd). It could optionally restricted to some simd types that are known to correspond to C types on the platform in question (e.g., permit f32x4 but not f32x3).

cc @alexcrichton

[alexcrichton]

Oh I was just under the impression we want to unconditionally ban simd types from C APIs. AFAIK the ABI is highly dependent on how C and Rust are compiled (target features and whatnot) and it's very tricky to get them to match up.

[hanna-kruppe]

Passing vectors as immediates has all these problems and therefore is feature gated separately (feature(simd_ffi)) but if SIMD types are not considered C-compatible, even passing pointers to them will trigger the lint, which I imagine would be very annoying.

[alexcrichton]

Oh sure yeah, I'd expect &mut u8x32 to work just fine, I'd only expect passing u8x32 as a bare value to "basically never work"

[retep998]

Doesn't the alignment of SIMD types depend on which target features are enabled? If so, isn't it bad when a pointer to a SIMD type is passed around when it was allocated with a lower alignment than expected by the receiving end?

[hanna-kruppe]

On the Rust side, it appears vectors are always naturally aligned (rounded up to the next power of two when needed? not that it matters for types you would see in FFI). The same seems to be true in C.

And now that I've thought about it, I can't really see how it could be any other way – type alignment is a global property, while target_feature can vary by function.

[hanna-kruppe]

So in the light of the above discussion I would propose:

• Declare some SIMD types FFI-safe irrespective of target features, based on architecture and element type and vector length. Which ones exactly is tbd, should probably be based on what C toolchains offer on the respective platform.
• Keep warning on repr(C, simd).
• Keep the simd_ffi feature gate which rules out passing SIMD types as immediates (this prevents any ABI mismatches due to different target_features)

[gnzlbg]

Declare some SIMD types FFI-safe irrespective of target features, based on architecture and element type and vector length. Which ones exactly is tbd, should probably be based on what C toolchains offer on the respective platform.

@rkruppe do you have a concrete example that works? That is, a platform, toolchain, and SIMD type, where passing a SIMD type by pointer to C via FFI works?

Do the target-features of the Rust and C binaries cause problem when passing for example a *mut f32x8 from Rust to C or vice-versa?