@gnzlbg ah yes so one clarifying point is that I’m assuming that the organization is all gated with scenarios to ensure platform-compatibility is still reasonable for downstream crates. In that sense I agree we’d dump them in the same module and avoid premature organization.
You brought up an important point, though, about target_feature. There are a number of intrinsics that are only available with AVX2, for example. My thinking, however, is that you can access these intrinsics no matter what. That is, so long as you’re compiling for a CPU architecture that could ever have an intrinsic, you have access to it. This solves the case where in general your code can’t use AVX but for small sections it can. I feel like it’d be too weird of a language feature to say the std::simd module had different contents based on where it was viewed from.
Note, though, that this hinges on the fact that LLVM can actually work with this (on a technical level). That is, if it actually causes a codegen error to call an avx2 function from a function where that’s not enabled then we have a whole new can of worms to deal with.
It’s true yeah, that LLVM will auto-vectorize based on enabled features so we can’t blanket do that. I also don’t think we can double/triple/etc the size of binaries just by compiling one with AVX and another without