Re: [PATCH v2] Aarch64: Add simd exp/expf functions

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 22/05/2019 17:54, Steve Ellcey wrote:
> Here is an updated version of my patch to add libmvec and vector exp
> functions to Aarch64.  GCC 9.1 has now been released so the build
> no longer depends on an unreleased compiler.  I have not added any
> assembly trampolines to allow older compilers to be used.
> 
> The SIMD ABI that this patch uses is supported by GCC 9.1 and is defined at:
> 
> https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-compiler-for-hpc/vector-function-abi
> 
> If you build with GCC 9.1 (or any compiler that supports the aarch64_vector_pcs
> attribute) you will get libmvec by default, otherwise you will not.  If you
> try to build libmvec using a compiler with out aarch64_vector_pcs support the
> configure will fail.

i just sent out the draft text of the ELF ABI yesterday that
addresses the lazy binding issue with sve and advsimd vector pcs.

this means gcc-9.1 does not produce abi conforming binaries,
a further gcc and binutils patch will be needed for that.

however not following the new ELF abi in libmvec.so itself should
be fine: the new ELF symbol marking is needed in the module that
has R_*_JUMP_SLOT relocations for vector symbols, i.e. on the
caller side. testing libmvec in glibc still works by luck since
lazy binding does not clobber problematic fp regs, and there are
no ifunc resolvers for vector math functions that use fp regs
either (the test binaries won't be abi conform though because
of the missing symbol marking).

(1) it is not obvious that we can enable libmvec in glibc
without a toolchain that follows the new ELF abi.

> There was a question of whether building libmvec should be optional or not,
> I don't have a strong opinion on that but would be interested in what others
> think.  I could change this to require aarch64_vector_pcs attribute support
> in all cases and always build libmvec if that is what we want.

if libmvec is conditional part of the glibc abi on aarch64
then binaries may not be portable between the same version
of glibc.

so either we make libmvec "experimental abi" for which you
have to explicitly opt in (not automatic based on compiler
support) or somehow ensure libmvec abi is present even if
the compiler building glibc has no support for the vector abi.

the latter can be achieved by a dummy libmvec (e.g. using
trivial asm) that provides the right symbols without optimal
implementations. (testing the dymmy libmvec is problematic
without compiler support though)

(2) we need to decide between 'experimental abi' or dummy libmvec
or increasing the minimum toolchain requirement.

(3a) in case of 'experimental abi' there has to be some
description about what users can expect and how to opt out
from using libmvec to build portable binaries.

(3b) in case of dummy libmvec the glibc mechanism to provide
it and test it should be figured out.

> I added static *_finite function names so that they are not exported.  If
> Wilco's patch to remove the *_finite names entirely is approved I can remove
> this part of the patch.
> 
> I removed the 'if (aarch64)' conditionals from math-vector-fortran.h
> (and fixed my use of the BIG_ENDIAN macros) this means that the vector exp
> and expf routines should get used in big-endian and little-endian modes for
> Fortran (just like C).  I have not done any big-endian testing at this point
> because I have been doing all my testing on a little-endian Aarch64 linux box.
> 
> If anyone has ideas on how to do big-endian testing I would be interested.
> I am guessing I would have to build an elf target and test with qemu or
> something like that but I haven't done a build/test setup like that in quite
> a while.

i'd like to get consensus around (1), (2), (3) first.

i don't yet have a proposal for how this should work.