This RFC is related to this glibc patch:

https://sourceware.org/ml/libc-alpha/2019-03/msg00106.html

and to this GCC discussion:

https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00532.html


The basic issue is that if you call a function like 'expf' with
GCC -Ofast, the glibc header file 'math-finite.h' gives it the
assembler name of __expf_finite.  Then, if you have a vectorized
version of this inlibmvec, GCC could wind up calling something like
'_ZGVnN4v___expf_finite' instead of '_ZGVnN4v_expf', even though these
are the same functionality on Aarch64 and X86.

There are a number of ways to handle this:

In my patch I just made _ZGVnN4v___expf_finite an alias for _ZGVnN4v_expf
and exported both from libmvec.so.  Joseph didn't like having the two
different names visible as part of the interface between GCC and glibc.

On X86 they have libmvec_nonshared.a, the *_finite routines are defined
here and they just call the 'normal' functions that are in libmvec.so.
I don't like this method because it means you have two calls to get to
the libmvec routine.

Joseph suggested putting a '__vector_name__' attribute on functions that
have libmvec vector version, then we could use that name (expf) instead
of the assembler name (__expf_finite) to form the libmvec name.  The 
objection here is that both C and Fortran would have to handle this new
attribute and anyone building glibc with a non GCC compiler would also
have to add support for the new attribute.



Here is another idea that I have and I would like to get opinions on
this approach.

On Aarch64, expf and expf_finite (and the other exp routines) are
aliases for each other and the vector versions would also be aliases,
so I would like to change math-finite.h to allow platforms to decide
whether or not to use the _finite names in calls.  This would affect
both the scalar and vector versions and all types (float, double, long
double).

As Joseph has said in the email from the threads referenced there is
really no reason why scalar and vector versions of different types
of a function like 'exp (expf, expl, etc) would agree on whether or
not they need different versions but in practice I am not sure this
will come up.  Here is an untested patch to give you an idea of what
I would like to do, obviously a real patch would be extend to put
the rest of the __MATH_REDIRCALL calls in math-finite.h inside of
ifdefs.  

Comments?

Steve Ellcey
sellcey@marvell.com


2019-13-03  Steve Ellcey  <sellcey@marvell.com>

	* bits/math-finite-funcs.h: New file.
	* bits/math-finite.h (exp): Put in ifdef.
	* math/Makefile: (headers): Add bits/math-finite-funcs.h.
	* math/math.h: Include bits/math-finite-funcs.h.
	* sysdeps/aarch64/fpu/bits/math-finite-funcs.h: New file.