Consider adding a SimdABI type parameter to select ABI

[gnzlbg]

We could extend Simd<[T; N]> to Simd<[T; N], SimdABI = DefaultSimdABI> to enable users to, for example, use Simd<[f32; 4], AVX> and generate code that assumes that AVX is available.

cc @rkruppe

[hanna-kruppe]

I don't understand how this could allow changing the (function call) ABI. The instructions used by operations on that ytpe, sure (though probably with all the same problems of mismatched target_features), but how could it affect the type is passed between functions in LLVM IR / machine code?

[gnzlbg]

My plan was to duplicate the implementation of the whole API per ABI, and for each ABI, #[target_feature(enable = "SimdAbi")] all functions and methods.

[gnzlbg]

The type passed is the same (#[repr(simd)] struct(f32,f32,f32,f32) => <4 x float>) - that does not change per "ABI" in this scheme. The only thing that would change is the target feature on that type's methods.

Something like a target-feature propagation pass in LLVM would deal with the rest: https://bugs.llvm.org/show_bug.cgi?id=41138