Andrew Lutomirski wrote:
Features like SSE2: enabling SSE2 as the basic floating point
changes the ABI drastically. But x86_64 already requires SSE2, so this is
For what it's worth, only the x86_64 ABI actually makes use of this. For
i686 (32-bit), even when Fedora moved to requiring SSE2, the ABI was not
changed (because that would have meant bootstrapping a whole new
architecture, breaking compatibility with all existing binaries in the
process). So i686 is stuck with the x87 ABI, copying floating-point data
back and forth between x87 and SSE registers.
Things like SSSE3, SSE3, SSE4, AVX1, AVX2, FMA, etc: for the most
these accelerate existing algorithms. I'm sure that someone somewhere has
written an algorithm that requires FMA for enhanced precision, but
otherwise pretty much any code that benefits from any of these features
would work just fine, if slower, without the features.
FMA can also be emulated in pure software (while still using hardware
floating-point instructions!), it is even implemented in glibc. So this also
falls under "would work just fine, if slower, without the features".
but FSGSBASE is not a credible requirement for Fedora since IIRC
supported on Sandy Bridge. Even Intel seems to consider Sandy Bridge to
be an important CPU to support.
AVX2 is also not supported on Sandy Bridge.
I think that, for vector extensions, Fedora shouldn't require
beyond SSE2 for basic functionality. Instead, Fedora should figure out
where there are material benefits to using them and find ways to make it
easier for packagers to make them available. Ideally this would all be
figured out at runtime,
but install-time choices could make sense, too.
I think we should just do it right and figure it out at runtime. Otherwise,
the user ends up having to manually install things such as those infamous
atlas-sse* subpackages, and most users will not bother doing that, or even
not even know that they exist or at least which one to pick.