You are not logged in.

#1 2021-02-07 05:42:20

Toolybird
Member
Registered: 2017-09-30
Posts: 36

Toolchain support for new x86-64 ABI's

There's been some interesting new developments in the "supported hardware" space.

Recently, 3 new microarchitecture levels were defined in the x86-64 psABI [1]. This allows software to take better advantage of modern CPU instruction sets.

Arch is currently compiled with -march=x86-64 which is equivalent to approx' circa 2003? [2].

Red Hat / Fedora have already started the ball rolling and are forging full steam ahead with x86-64-v2 [3][4]. The interesting thing for them is, they are leaving 2003 in the dust. Arch doesn't have to do same, but could easily support the new ABI's via the newly enhanced hwcaps mechanism freshly minted in glibc-2.33.

Try this for example:

$ /lib/ld-2.33.so --help

On my AMD Ryzen system it shows:

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

You can easily see the new hwcaps in action with strace:

$ echo 'int main(){}' | gcc -x c -
$ LD_LIBRARY_PATH=/foo strace ./a.out

What this means is we can *today* place an optimised library into:

/usr/lib/glibc-hwcaps/x86-64-v2/

and instantly reap benefits via CPU instructions available in our modern hardware.

We are still waiting on release of GCC-11 before you can compile directly with the new -march flags eg: -march=x86-64-v2

Anyway, food for thought. Hopefully the Arch developers are looking into this stuff for the future.

Cheers


[1]: https://gitlab.com/x86-psABIs/x86-64-ABI
[2]: https://lists.llvm.org/pipermail/llvm-d … 43633.html
[3]: https://developers.redhat.com/blog/2021 … ure-level/
[4]: https://src.fedoraproject.org/rpms/redh … ch=rawhide

Offline

#2 2021-02-12 21:56:41

Allan
Member
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,028
Website

Re: Toolchain support for new x86-64 ABI's

There has been discussions about providing higher optimization levels in Arch packages.  However, our package signing process currently requires the individual packager to sign, whereas we want the more optimized packages to be build automatically.  This is being worked on (we want databases to be signed automatically too!).

Offline

Board footer

Powered by FluxBB