[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |---
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com
   Last reconfirmed|                            |2020-04-22
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1

--- Comment #9 from Florian Weimer <fweimer at redhat dot com> ---
I'm happy to report that I've been in contact with the right people at AMD for
a while.

I do not know yet what the exact outcome will be (if the “haswell” directory
will be used), but there will be a way to automatically load AVX2-optimized
libraries on AMD CPUs as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[david.abdurachmanov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

David Abdurachmanov <david.abdurachmanov at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.abdurachmanov at gmail dot c
                   |                            |om

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
I surveyed the existing code and wrote a summary:

hwcaps subdirectory selection in the dynamic loader
<https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #11 from Mingye Wang <arthur200126 at gmail dot com> ---
I agree that a "generational" revision scheme would be helpful in the long run.
For that information we can consult compiler databases
(gcc/gcc/common/config/i386/i386-common.c + gcc/config/i386/i386.h or
llvm/clang/include/clang/Basic/X86Target.def) and make some sort of table to
work with.

The LLVM project's version seems to already imply a generational scheme,
although they appear to be taking a lot of liberties by eliding a lot of the
stuff they don't use. They also don't seem to care about less-used stuff like
VIA.

The GCC database does include the VIA CPUs, but the part about eden-x4 not
having any sort of AVX is a bit dubious. Hell, their documentation mentions it
having AVX2...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[tcl_de at gmx dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

tcl_de at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tcl_de at gmx dot net

--- Comment #12 from tcl_de at gmx dot net ---
Regarding VIA, the GCC onlinedocs say that eden-x4 supports AVX and AVX2, but
as you have pointed out, they are not enabled in GCC's i386-common.c. I have
had a look at CPUID dump from the instlatx64 project for an eden-x4 (see
http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls00006FE_CNR_Isaiah_CPUID.txt
) and if I decode it correctly, the GCC onlinedocs also miss some supported
instruction sets: MOVBE, POPCNT, AES, PCLMUL, FSGSBASE, RDRND, BMI, BMI2 and
F16C.
This means that all instruction sets listed for Haswell should be supported
except for FMA.
As far as I can tell, if RDRND is also removed from the list, this is the least
common denominator among all AVX2 cpus (technically bdver4 supports RDRND, but
Linux disables it by default due to buggy BIOS support, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c49a0a80137c7ca7d6ced4c812c9e07a949f6f24)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #13 from Mingye Wang <arthur200126 at gmail dot com> ---
> Regarding VIA, the GCC onlinedocs say that eden-x4 supports AVX and AVX2, but as you have pointed out, they are not enabled in GCC's i386-common.c.

I have reported the problem to gcc as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95030. Let me forward your cpuid
links.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[tcl_de at gmx dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #14 from tcl_de at gmx dot net ---
(In reply to Mingye Wang from comment #13)
> > Regarding VIA, the GCC onlinedocs say that eden-x4 supports AVX and AVX2, but as you have pointed out, they are not enabled in GCC's i386-common.c.
> 
> I have reported the problem to gcc as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95030. Let me forward your
> cpuid links.

Thanks for forwarding the information. I just realized that when I had a look
at the CPUID dump, I overlook something, as I only focussed on the instruction
sets list for haswell, but the eden-x4 actually supports a few more that are
not in that list: PREFETCHW, RDSEED, ADX, ABM, XSAVE, and maybe also XSAVEOPT
and XSAVEC, but I am not sure about the latter two.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #15 from Mingye Wang <arthur200126 at gmail dot com> ---
Created attachment 12811
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12811&action=edit
What I think the discussion is going for

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #16 from Florian Weimer <fweimer at redhat dot com> ---
Sorry, I didn't update the ticket. I think the consensus is not to make further
changes to the existing hwcaps mechanism due to the issues mentioned in comment
10.

Instead, we are focusing on a new approach:

https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html

The psABI document has been updated:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9a6b9396884b67c7c

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.33
             Status|NEW                         |RESOLVED

--- Comment #17 from Florian Weimer <fweimer at redhat dot com> ---
This is effectively fixed in glibc 2.33 by:

commit f267e1c9dd7fb8852cc32d6eafd96bbcfd5cbb2b
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Dec 4 09:13:43 2020 +0100

    x86_64: Add glibc-hwcaps support

    The subdirectories match those in the x86-64 psABI:

   
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9a6b9396884b67c7c

    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Libraries for Epyc and other current AMD CPUs need to installed into
glibc-hwcaps/x86-64-v3 subdirectory in order to be picked up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[josephriches at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #18 from Joey Riches <josephriches at gmail dot com> ---
Will glibc still load from from `/usr/lib64/haswell` or will that functionality
be stripped out? 

Unfortunately x86_64-v3 includes XSAVE instructions which excludes haswell so
moving to x86_64-v3 will be a performance regression for our haswell users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #19 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Joey Riches from comment #18)
> Will glibc still load from from `/usr/lib64/haswell` or will that
> functionality be stripped out? 

No formal decision has been made about this.

> Unfortunately x86_64-v3 includes XSAVE instructions which excludes haswell
> so moving to x86_64-v3 will be a performance regression for our haswell
> users.

XSAVE is *required* for AVX register support. If a Haswell-based system does
not support this feature, the kernel has been booted with the “noxsave” option,
or a hypervisor has been misconfigured.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[josephriches at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #20 from Joey Riches <josephriches at gmail dot com> ---
Thanks for the clarification, the confusion stemmed from gcc docs not listing
xsave for haswell. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Thanks again for all the work on this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/23249] Epyc and other current AMD CPUs do not select the "haswell" platform subdirectory

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23249

--- Comment #21 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Joey Riches from comment #20)
> Thanks for the clarification, the confusion stemmed from gcc docs not
> listing xsave for haswell.
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

Ah, right, that's one of the issues raised in the sister bug 24080.

-- 
You are receiving this mail because:
You are on the CC list for the bug.