* 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
