Re: [PATCH] Move declare_mgen_finite_alias definition

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:

> Anyway, let me elaborate: we created a new template that uses this macro
> and the directory sysdeps/ieee754/ldbl-128ibm-compat/.

What's that directory for?  Defining float128 functions (why can't you 
make the float128 sysdeps directory do the right thing?)?  Defining ibm128 
functions (what's wrong with the ldbl-128ibm sysdeps directory?)?  
Something else?  What other (existing) sysdeps directories for 
floating-point types would you propose to use in the sysdeps directory 
ordering?  What format would long double have when compiling code in those 
directories?

> We're using template techniques to provide the new symbols instead of what
> was adopted with float128_private.h.  We haven't replaced this header (yet?),
> though.  The redefinition of macros that float128_private.h does, reached a
> limit and became too complex to deal with.

It's true that I think float128_private.h should eventually be replaced 
with the ldbl-128 functions being set up to always provide the *f128 names 
and then conditionally provide the *l names as well as aliases (and parts 
of that could be done incrementally, e.g. explicitly using FLT128_* 
instead of LDBL_* constants in the ldbl-128 code).

But I don't think the type-generic template system has anything to do with 
code that is not type-generic.

> With these macros, we can reuse code without redeclaring macros with the name
> of functions.  We can also redefine them per float type and directory, e.g.
> sysdeps/ieee754/ldbl-128ibm-compat/math-type-macros-float128.h.
> 
> This is an example of a file, using a sister-macro.
> sysdeps/ieee754/ldbl-128ibm-compat/e_acosf128.c:
>     #include <math-type-macros-float128.h>
>     
>     #include "../float128/e_acosf128.c"
>     
>     #undef __acosl_finite
>     #undef __acosl
>     
>     declare_mgen_finite_alias2 (__ieee754_acos, __acos)

I don't think that's a good approach - I don't think the type-generic 
template system should be used with code that is not type-generic.  The 
libm_alias_* macros are intended for use in type-specific function 
implementations (they are currently for *public, once-per-type* aliases, 
rather than internal names or *once-per-format* implementation namespace 
exported aliases - but additional macros for internal names could be added 
in e.g. the case of float128_private.h removal, where you'd have e.g. 
__ieee754_acosf128 as an unconditional name, __ieee754_acosl as a name 
only if that format is the default long double and likewise exactly one of 
__acosl_finite and __acosf128_finite).

The obvious starting point for binary128 long double support on 
powerpc64le would seem to me to be just to get the installed headers to 
arrange for calls to *l to be asm-redirected to call *f128.  That doesn't 
quite work because (a) it's not namespace-clean and (b) there are a few 
obsolescent functions with no public *f128 names which shouldn't get such 
names, but are part of the *l API so need to be available for long double 
in the -mabi=ieeelongdouble case, so you may actually want to call new 
__*f128 names instead (so get libm_alias_float128* to define those, maybe 
with new macro variants as needed, and watching out for cases where 
__*f128 already exists but isn't what *f128 is aliased to).  If you're 
instead using new *l symbol versions and new exported names for ibm128 
functions (which seems to me to increase the number of exported symbols 
unnecessarily), much the same applies (except you also need to make 
ldbl-128ibm functions use libm_alias_ldouble because I skipped those 
functions as not relevant to my _FloatN/_FloatNx work).

-- 
Joseph S. Myers
joseph@codesourcery.com