aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT

[Szabolcs Nagy]

On 19/04/18 15:38, Adhemerval Zanella wrote:
> On 19/04/2018 08:51, Szabolcs Nagy wrote:
>> This enables searching shared libraries in atomics/ when the hardware
>> supports LSE atomics of armv8.1 so one can provide optimized variants
>> of libraries in a portable way.
>>
>> LSE atomics does not affect library abi, the new instructions can
>> interoperate with old ones.
>>
>> I'm not familiar with how this feature of the dynamic linker is used
>> in practice by distros or others so comments are welcome.
> 
> Clearlinux seems to use this to provide optimized Intel libraries [1].
> 

interesting thanks.

>> 2018-04-19  Szabolcs Nagy  <szabolcs.nagy@arm.com>
>>
>>  Â Â Â Â * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add
>>  Â Â Â Â HWCAP_ATOMICS.
> 
> I think what you want is something what x86_64 has done [2]: on cpu-features.c
> the code creates a list of possible processor specific paths and sets it do
> GLRO(dl_platform) (for instance on x86_64 if the underlying system is a haswell
> it will add the haswell folder path).
> 
> Currently since AArch64 do not change dl_platform_init, it adds 'aarch64' from
> AT_PLATFORM and 'cpuid' because of HWCAP_IMPORTANT.  IMHO neither does make
> sense as search paths, I would expect at least the 'cpu_list' from aarch
> cpu-features.c (maybe by excluding the 'generic' field).
> 

i don't know the reasons behind 'aarch64' and 'tls' search paths
and i have no particular attachment to the HWCAP_IMPORTANT mechanism.

> So I suggest to rework how aarch64 obtain the search path by setting the
> dl_platform in cpu-features.c:
> 
>    - We can get the cpu_list if HWCAP_CPUID, so add only current cpu folder
>      if it the case.
> 
>    - If HWCAP_ATOMICS is set add 'lse'.
> 

if these paths are for optimization only then i guess the list
can change between libc releases without causing issues other
than performance regressions.

in that case i'm in favor of removing unnecessary search paths.

atomics i think is a useful variant, i'll think about the cpuid
based search paths, i don't want too many variants since nobody
will prepare/test binaries for all uarch variants, but i do like
the ability to have alternative optimized libs.

>    - Any more required?
> 
> [1] https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
> [2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1432d38ea04ab5e96f21a38;hp=3b5f801ddb838311b5b05c218caac3bdb00d7c95
>