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

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

On 06/03/2019 20:54, Steve Ellcey wrote:
> On Wed, 2019-03-06 at 20:45 +0100, Florian Weimer wrote:
> 
>>>> Can you add assembler trampolines, so that the compiler support
>>>> becomes optional, at a performance cost?
>>>
>>> Yuck.  I suppose this is possible, but I do not want to do it.
>>> The whole reason for vector functions (and for the new vector ABI)
>>> is performance so adding a slow path doesn't seem to me like it is
>>> worthwhile.
>>
>> On the other hand, it could help to get libmvec out of the door more
>> quickly.  I think it's not ideal that if you use an older compiler,
>> you get only a subset of the glibc ABI.  We can get away with it here
>> because it affects an entire soname.  Still it might be difficult to
>> explain why applications are not portable.
> 
> If the user doesn't have gcc-9, their compiler isn't going to generate
> any calls to these routines anyway.  So it doesn't really matter if 
> they have libmvec or not if they don't have gcc-9.  If a program was
> compiled with gcc-9 somewhere else and then moved, then yes the new
> platform might not have libmvec and there will be portability problems.

glibc is probably built with a stable distro gcc, but then the user
may use a trunk gcc to compile code.

of course with trampolines vector math functions may not be worth to
call at all, so it's not clear if having a libmvec with trampolines is
useful other than allowing the glibc abi to be independent of the gcc
version used to compile it.

On 06/03/2019 19:16, Florian Weimer wrote:
> I don't think the binutils change is needed for building or testing
> glibc, at least not initially.  Just disable lazy binding.

in principle libmvec dso as well as anything that references vector
pcs symbols would need to be linked with -z now, and even that's
not enough if we ever want to support LD_AUDIT (which is like
permanent lazy binding). i originally thought i can fix this up
with some simple hack, but it will need a bigger change across the
toolchain, i hope i can post some patches soon and then we can
discuss what to do in glibc.

On 06/03/2019 17:18, Steve Ellcey wrote:
> +  g = __builtin_aarch64_absv2df (x);
> +  h = __builtin_aarch64_reduc_smax_scal_v2df (g);

please use arm_neon.h intrinsics instead of __builtin_aarch64_*, these
are not documented gcc apis, so they may change.