Re: RFC: Patch to avoid using _finite calls in some cases (including in libmvec names)

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 13 Mar 2019, Steve Ellcey wrote:

> 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.

Fortran would not have to handle that attribute.  Fortran never gets 
_finite names in the first place because it can't parse the C header which 
is how C code gets the _finite names.

In the powerpc64le long double context, Fortran (and other languages 
working with C libraries such as D) not parsing C headers requires some 
special compiler support to handle remapping the names of relevant library 
functions (or else glibc support for generating lists of remappings for 
use from other languages, etc.).  But in the libmvec context, those 
languages not parsing C headers means that _finite isn't an issue at all 
for libmvec use for such languages.

> On Aarch64, expf and expf_finite (and the other exp routines) are
> aliases for each other and the vector versions would also be aliases,

That's not the case for expl, which by itself makes this patch suboptimal 
(losing use of __expl_finite while it still does something more efficient 
than expl).

> 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).

We also know that significant changes to handling of _finite functions 
will be needed to avoid double redirections (which don't actually work) 
for non-default long double formats.  See bug 23292 (and my review saying 
this indicates merging bits/math-finite.h into bits/mathcalls.h).  It's 
not clear how a version using __MATHCALL_FINITE or similar to declare 
functions in bits/mathcalls.h could readily handle such per-function, 
per-architecture, per-type conditionals.

I still think independent asm names for scalar and vector functions is the 
right approach here.

-- 
Joseph S. Myers
joseph@codesourcery.com