Safe intrinsics in core::arch

[veluca93]

Proposal

Problem statement

With target features 1.1 now ready to be stabilized, it is soon going to be possible to write i.e. intrinsics-using SIMD code with minimal use of unsafe (specifically, only at the initial entry point of feature-using code.

However, most intrinsics in core::arch are currently unsafe (excluding wasm32 intrinsics), requiring user code to introduce some amount of unsafe at the lowest level of the call hierarchy too.

Motivating examples or use cases

For example, the DCT code in jpeg-decoder (here) could reduce usage of unsafe to effectively just a couple of lines, making the code significantly easier to audit.

This is common to multiple SIMD-using crates.

Solution sketch

Arch-specific intrinsics (such as AVX/AVX2 SIMD intrinsics) in core::arch that do not operate on pointers, and do not affect global state (such as FP rounding modes) could be made safe once target_features 1.1 is stabilized.

Alternatives

An alternative would be for people to write/use a crate that wraps relevant core::arch intrinsics in safe wrappers.

[Amanieu]

We discussed this in the libs-api meeting and we're happy to accept. This is technically a breaking change since (in theory) someone could take a function pointer to an intrinsic function. However since this is very unlikely we are happy to consider this after a crater run.