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

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

* Carlos O'Donell via Libc-alpha:

> 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.

I disagree; for a subset of the directories, we should guarantee
stability.

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

Agreed.  Programmers need to assume that future glibc versions may
stop selecting certain subdirectories.  However, I'm not sure if we
can suddenly start selecting directories on systems where we did not
do so before.

> 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.

I don't think that works.

> 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.

The results for (b) also feed into (a) to some extent because if
research for (b) reveals that certain CPU features have been disabled
by microupdate updates, we probably do not want them for (a), either.