It’s worth noting that this process is unfinished, because I failed to add a CI job to actually have the glibc Linux release artifacts generated.
While I think adding NEON-enabled targets is the right step at this point in time (no SIMD vs. baseline 128-bit SIMD is a pretty big deal), the approach of adding targets won’t scale for SSE and AVX levels. As mentioned in my Rust 2019 post, I think the way forward is to put Xargo functionality into Cargo and compile the standard library with user settings like all other crates (hopefully with some caching).
As for what defaults make sense, if my cpuid criteria was correctly researched, as of June 2018, 20% of the Firefox x86/x86_64 release population was still on the kind of x86/x86_64 CPU where there’s a substantial performance disparity between aligned and unaligned SIMD loads and stores with actually aligned addresses. IIRC performant unaligned SIMD loads and stores roughly correlate with SSE 4.2 availability. So the landscape is very different when considering an application run by basically everyone, like a Web browser, than when considering gaming systems (Steam numbers).
(Specifically, the criteria that matched 80% was: (cpu_family >= 0x15) OR (cpu_family == 0x6 AND cpu_model >= 0x1A AND cpu_model != 0x1C AND cpu_model != 0x36 AND cpu_model != 0x35 AND cpu_model != 0x27 AND cpu_model != 0x26).)
Of course, separating x86 and x86_64 could give different numbers that could justify changing the baseline SSE level on x86_64. (Meanwhile, bringing the baseline to SSE2 on x86 is still a new thing: Fedora is moving to it. In the case of Ubuntu, dropping x86 install support seems less controversial than compiling 32-bit packages in SSE2 mode!)
In any case, it seems to me that making cargo install default to native should be the first step even if it means that people will routinely run the compiler with options that aren’t the ones tested in CI.
