Open gnzlbg opened 5 years ago
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?
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.
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
We could extend
Simd<[T; N]>
toSimd<[T; N], SimdABI = DefaultSimdABI>
to enable users to, for example, useSimd<[f32; 4], AVX>
and generate code that assumes thatAVX
is available.cc @rkruppe