I agree with @felix.s here: we can do whatever we want with x86_32 and x86_64 “generic” targets, but the i{386,586,686,786,...} targets should work on the architectures that they are actually targeting “without buts”.
This does not impact users exclusively, parts of std (like stdsimd) have some messy code to deal with the “differences” between the Rust targets and “real life”. Just because Rust says that all i686 targets have SSE2 enabled (like the Pentium 4 does) does not make it that way (e.g., Pentium Pro, Pentium 2, and Pentium 3 are all i686 CPUs and they don’t have SSE2).
I don’t know who thought that any of this was a good idea and I haven’t been able to find any comments / discussions about why things are the way they are, but it has only led to pain down the road.
This is also why I am a bit skeptic about -C target-feature hierarchies: Intel does not assume a hierarchy, and some Intel CPUs have violated this in the pass and might do so again. I would be more comfortable with adding targets that enable multiple features (and document which feature they enabled), than about making avx512 implicitly enable avx2, for example. If anyone wants to pursue feature hierarchies they should do so with different names, like we currently do for the crypto feature. For example simd128 to enable sse…sse4.2, or simd256 to enable avx, avx2, and simd128.
