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

[Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>]

On 3/17/20 3:27 PM, Adhemerval Zanella via Libc-alpha wrote:
> On 17/03/2020 10:17, Carlos O'Donell via Libc-alpha wrote:
>> 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?

It should be subject to change just like tunables.

It should be an optimization, and not a requirement, and applications
should always provide a fallback implementaiton to allow the application
to load.

Failure to load the libraries *may* result in a failure to start the
application and we need to be OK with that. That is to say that a
particularly package may only ship an optimized library (going against
the recommendation).

We should verify that downstream distributions can use /etc/ld.so.conf
as a way to add back directories into the search of the existing 
additional multilib search directories e.g. Add back /lib64/haswell
for a few years.

Does that answer your question?
 
> 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.

Yes.

>> 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])?

In the end I think we'll want:

(a) Try CPU vendor directories first.
- Each vendor should name their directories and the explicit
  compiler options to target them (printed by LD_DEBUG).

(b) Try shared directories second.
- Based on a common set of identified features.
  - Compiler options to target the shared set should be explicitly
    stated (printed by LD_DEBUG).

My understanding is that Florian is asking for help with (b)
to identify what things should be enabled for current CPUs, and
that we'll compare that list to the Intel list and make a common
shared directory that the downstream distributions can used
for the most optimized library we can have in common.

What we can do:
- Cleanup the generic code to allow a CPU vendor split?
  - We have a mix of hwcap bit handling and list handling
    for platforms. This is also a bit messy.
  - Allow vendors to drop in their CPU vendor search list
    ahead of the shared list, again based on feature presence.
- Prepare the code for a shared common directory based on
  some shared subset of features, and enable it only if
  those features are present. Today doing this is a bit
  messy in cpu-features.c.


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

-- 
Cheers,
Carlos.