Re: New x86-64 micro-architecture levels

[Florian Weimer <fweimer@redhat.com>]

* Premachandra Mallappa:

> [AMD Public Use]

>>> Also we would also like to have dynamic loader support for "zen" / 
>>> "zen2" as a version of "Level D" and takes preference over Level D, 
>>> which may have super-optimized libraries from AMD or other vendors.
>
>> *That* shouldn't be too hard to implement if we can nail down the selection criteria.  Let's call this Zen-specific Level C x86-zen-avx2 for the sake of exposition.
>
> Some way of specifying a superset of "level C" , that "C" will capture fully.
>
> Zen/zen2 takes precedence over Level C, but not Level D, but falls
> back to "Level C" or "x86-avx2" but not "x86-avx".
>
> I think it is better to run a x86-zen on a x86-avx2 or x86-avx
> compared to running on a base x86_64 config.

We discussed this off-list for a bit and concluded that we do not want
to address this as part of this proposal.

I went ahead and created a merge request against the x86-64 psABI
supplement:

  <https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/8>

I used x86-64-v2 etc. as the level names, picking up the suggestion to
use x86-64 there.  I think we don't need to share names with 32-bit (if
that ever happens), as explained here:

  <https://sourceware.org/pipermail/libc-alpha/2020-July/116536.html>

There are only three new levels (level B was merged into level C).

I tried to make precise the meaning of the levels by matching them to
CPU features, based on their CPUID detection logic.  It's somewhat
complicated, but I think it's within reason for the task at hand.

Thanks,
Florian