Re: [PATCH 0/3] RFC: Platform Support for AMD Zen and AVX2/AVX

[Florian Weimer <fw@deneb.enyo.de>]

* Prem Mallappa via Libc-alpha:

> From: Prem Mallappa <Premachandra.Mallappa@amd.com>
>
> Hello Glibc Community,
>
> == (cross posting to libc-alpha, apologies for the spam) ==
>
> This is in response to
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24979
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24080
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=23249
>
> It is clear that there is no panacea here. However,
> here is an attempt to address them in parts.
>
> From [1], enable customers who already have
> "haswell" libs and has seen perf benifits by loading
> them on AMD Zen.
> (Load libraries by placing them in LD_LIBRARY_PATH/zen
> or by a symbolic link zen->haswell)
>
> From [2] and [3]
> And, A futuristic generic-avx2/generic-avx libs,
> enables OS vendors to supply an optimized set.
> And haswell/zen are really a superset, hence
> keeping it made sense.
>
> By this we would like to open it up for discussion
> The haswell/zen can be intel/amd
> (or any other name, and supply ifunc based loading
> internally)

I think we cannot use the platform subdirectory for that because there
is just a single one.  If we want a Intel/AMD split, we need to
enhance the dynamic loader to try the CPU vendor directory first, and
then fallback to a shared subdirectory.  Most distributions do not
want to test and ship binaries specific to Intel or AMD CPUs.

That's a generic loader change which will need some time to implement,
but we can work on something else in the meantime:

We need to check for *all* relevant CPU flags such code can use and,
and only enable a subdirectory if they are present.  This is necessary
because virtualization and microcode updates can disable individual
CPU features.

For the new shared subdirectory, I think we should not restrict
ourselves just to AVX2, but we should also include useful extensions
that are in practice always implemented in silicon along with AVX2,
but can be separately tweaked.

This seems to be a reasonable list of CPU feature flags to start with:

  3DNOW
  3DNOWEXT
  3DNOWPREFETCH
  ABM
  ADX
  AES
  AVX
  AVX2
  BMI
  BMI2
  CET
  CLFLUSH
  CLFLUSHOPT
  CLWB
  CLZERO
  CMPXCHG16B
  ERMS
  F16C
  FMA
  FMA4
  FSGSBASE
  FSRM
  FXSR
  HLE
  LAHF
  LZCNT
  MOVBE
  MWAITX
  PCLMUL
  PCOMMIT
  PKU
  POPCNT
  PREFETCHW
  RDPID
  RDRAND
  RDSEED
  RDTSCP
  RTM
  SHA
  SSE3
  SSE4.1
  SSE4.2
  SSE4A
  SSSE3
  TSC
  XGETBV
  XSAVE
  XSAVEC
  XSAVEOPT
  XSAVES

You (as in AMD) need to go through this list and come back with the
subset that you think should be enabled for current and future CPUs,
based on your internal roadmap and known errata for existing CPUs.  We
do not need a rationale for how you filter down the list, merely the
outcome.

(I already have the trimmed-down list from Intel.)