[arch-dev-public] Create guidelines regarding SIMD instructions/x86 extensions

Filipe Laíns lains at archlinux.org
Sat May 25 00:17:02 UTC 2019


Currently there are no guidelines stating which x86 extensions (ex.
SSE2, SEE3, SSE4, AVX, etc.) we support. This is a bit problematic
since it lets compilers do what they want and possible generate code
that can't run on some systems.

Even though this is an issue, it's not complete anarchy, at least yet!
Just kidding :p. The vast majority of our native packages are compiled
with GCC and we do default to `-mtune=generic` which is good but not
optimal. `-mtune=generic` tells GCC to compile for a generic processor
so it's up to GCC to decide which architecture extensions would compose
a generic processor. I haven't been able to find any documentation on
what x86 extensions are enabled for a "generic" processor but I was
able to track them down to MMX, SSE (or KNI) and SSE2. Being
undocumented they could change at any time so I don't think we should
rely on `-mtune=generic`.

What I propose is to define a set of x86 extensions to support and make
all compilers default to that if possible. I am fine with MMX, SSE and
SSE2 but they should be *our* choice, not GCC's.

This begs the question, would such approach be doable? So I ask the
compiler maintainers to please check if this would be possible.

I would also like to explore the idea of adding an "high performance"
architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and
AVX, which seem to be the standard for newer processors (>=2013). This
would only be available for packages that do high performance computing
(ex. openblas, sdrangel, etc.). Any thoughts on this?

Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190525/56edc31d/attachment.sig>

More information about the arch-dev-public mailing list