Reduce use of unsafe in portable SIMD library

[robertknight]

The current low-level SIMD operations in rten-simd are all unsafe because they are thin wrappers around intrinsics in core::arch and therefore the caller needs to have verified that the instructions are supported before using them. It would be nice to find ways to reduce the amount of unsafe code here.

Constraints

• We should prefer to use SIMD types of the natural width (ie. which fill a complete register), so as to get the maximum benefit from parallelism. This means 4 x f32 on Arm Neon/wasm32, 8 x f32 on AVX2, 16 x f32 on AVX-512 and so on. In future we'll also need to deal with flexible vector instruction sets like SVE where the vector length is unknown at compile time (but is fixed at runtime).

Sources of inspiration

• std::simd avoids the issue by using SIMD types with a fixed-width which can be implemented for every architecture. A given SIMD type will just be mapped to different instructions when used depending on active target features
• pulp - Safe portable SIMD library for Rust with dynamic dispatch. This handles the issue by making the Simd trait represent an instruction family with operations and associated vector types, not a SIMD vector. This trait is then impl-ed by types which can only be constructed if the feature set is available.
• Portable SIMD libraries in C++. There isn't a language-level concept of safety in C++ but there might still be some ideas here
  • Vectorized types in PyTorch
  • Highway

[robertknight]

Related to this, one issue with rten-simd and rten-vecmath right now is that you can't use Miri on it, which would help identify bugs in unsafe code, due to lack of support for various SIMD intrinsics. See also rust-lang/miri#1912.

[robertknight]

Related upstream issue: rust-lang/libs-team#494