[2/2] aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANT

  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 considered the earlier comments on the patch

https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html
https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html

It turns out that the way glibc dynamic linker decides on the search
path is not very flexible: it wants to use hwcap bits and associated
strings.  So some targets reuse hwcap bits for glibc internal purposes
to affect the search logic.  But hwcap is an interface with the kernel,
glibc should not allocate bits in it for its internal logic as that
limits future hwcap extensions and confusing to users who expect to see
hwcap bits in ifunc resolvers.  Instead of rewriting the dynamic linker
path logic (which affects all targets) this patch just uses the existing
mechanism, however this means that the path name has to be the hwcap
name "atomics" and cannot be changed to something more meaningful to
users.

It is hard to tell how much performance benefit this can give, in
principle armv8.1 atomics can be better optimized in the hardware, so it
can make a difference for synchronization heavy code.  On some systems
such multilib setup may be the only viable way to get optimized
libraries used.

2018-06-28  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	* sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add
	HWCAP_ATOMICS.
---
  sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
  

On 28/06/18 19:25, 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 considered the earlier comments on the patch
> 
> https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html
> https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html
> 
> It turns out that the way glibc dynamic linker decides on the search
> path is not very flexible: it wants to use hwcap bits and associated
> strings.  So some targets reuse hwcap bits for glibc internal purposes
> to affect the search logic.  But hwcap is an interface with the kernel,
> glibc should not allocate bits in it for its internal logic as that
> limits future hwcap extensions and confusing to users who expect to see
> hwcap bits in ifunc resolvers.  Instead of rewriting the dynamic linker
> path logic (which affects all targets) this patch just uses the existing
> mechanism, however this means that the path name has to be the hwcap
> name "atomics" and cannot be changed to something more meaningful to
> users.
> 
> It is hard to tell how much performance benefit this can give, in
> principle armv8.1 atomics can be better optimized in the hardware, so it
> can make a difference for synchronization heavy code.  On some systems
> such multilib setup may be the only viable way to get optimized
> libraries used.
> 

committed.

distros were not enthusiastic about this approach, but
in the worst case nobody will use these "atomics/" paths
(and we waste a few open syscalls) and in the best case
it enables performance improvement for some users.

> 2018-06-28  Szabolcs Nagy  <szabolcs.nagy@arm.com>
> 
>      * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add
>      HWCAP_ATOMICS.
> ---
>   sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)