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

[Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>]

On 17/03/2020 10:17, Carlos O'Donell via Libc-alpha wrote:
> On 3/17/20 5:02 AM, Florian Weimer wrote:
>> * 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.
> 
> I agree. The additional burden on testing, maintaining, and supporting
> distinct libraries is not feasible.
> 
>> 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.
> 
> Agreed. This is the only sensible plan. The platform directories already
> imply some of this, but it's not well structured.

Which should be our policy regarding the platform name over releases?
Should the names set in previous release being supported in a 
compatibility manner or should it not be constraint (as for tunables)
and subject of change?

If the former, with a defined subset of the CPU features flags it might
be possible to share folder over x86 chips without using chips release
names.

> 
>> 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.
> 
> Agreed.
> 
>> 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.
> 
> And this is the hard part that we can't solve without AMD's help.
> 
> Even if you ignore "future CPUs" it would be useful to get this list
> for all current CPUs given your architectural knowledge, errata, and
> other factors like microcode, that covers the currently released CPUs.

So the question is how should be move forward: let the chip vendor
(Intel, AMD, etc.) define its own naming scheme based on its own
chip roadmap, or create subsets of features to set a common naming
folder (as suggested by Richard Biener on BZ#24080 [1])?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24080