Move declare_mgen_finite_alias definition

  Move declare_mgen_finite_alias, declare_mgen_finite_alias_s and
declare_mgen_finite_alias_x to a shared place in order to reuse them in
other files that also declare _finite aliases.

2018-05-11  Tulio Magno Quites Machado Filho  <tuliom@linux.ibm.com>

	* math/e_exp2_template.c (declare_mgen_finite_alias,
	declare_mgen_finite_alias_s, declare_mgen_finite_alias_x): Move to...
	* sysdeps/generic/math-type-macros.h (declare_mgen_finite_alias,
	declare_mgen_finite_alias_s, declare_mgen_finite_alias_x): ... here.
---
 math/e_exp2_template.c             |  7 -------
 sysdeps/generic/math-type-macros.h | 15 +++++++++++++++
 2 files changed, 15 insertions(+), 7 deletions(-)
  

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

> Move declare_mgen_finite_alias, declare_mgen_finite_alias_s and
> declare_mgen_finite_alias_x to a shared place in order to reuse them in
> other files that also declare _finite aliases.

I don't see any other type-generic templates declaring such aliases, so 
you'll need to give more explanation of why this is useful.
  

Joseph Myers <joseph@codesourcery.com> writes:

> On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:
>
>> Move declare_mgen_finite_alias, declare_mgen_finite_alias_s and
>> declare_mgen_finite_alias_x to a shared place in order to reuse them in
>> other files that also declare _finite aliases.
>
> I don't see any other type-generic templates declaring such aliases, so 
> you'll need to give more explanation of why this is useful.

They are indeed not used right now.
Both this patch and the M_DECL_FUNC_R* one are preparing terrain for larger
patch sets.  I thought this would be easier to review, but we can delay the
review of this patch if you prefer.

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

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.

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)
  

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

On Fri, 11 May 2018, Joseph Myers wrote:

> 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 

(Or use e.g. __*ieee128 or similar as the exported aliases instead of 
__*f128, and then you wouldn't need any separate cases according to 
whether __*f128 already exists internally.)
  

Joseph Myers <joseph@codesourcery.com> writes:

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

It's holding files that functions that must not be in
ieee754/ldbl-128ibm and ieee754/float128.  It's just a layer for
ieee754/ldbl-128ibm and ieee754/float128, e.g. string-related functions and
files that required symbol treatment.

> Defining float128 functions (why can't you 
> make the float128 sysdeps directory do the right thing?)?

My example was indeed terrible.  I agree float128/e_acosf128.c should be
doing this.

> Defining ibm128 functions (what's wrong with the ldbl-128ibm sysdeps directory?)?

They're still there.
We're reusing everything from float128 and ldbl-128ibm as possible (minus
mistakes like the previous one  :-D ).

> Something else?  What other (existing) sysdeps directories for 
> floating-point types would you propose to use in the sysdeps directory 
> ordering?

I didn't understand your questions.
ldbl-128ibm-compat is the only sysdeps directory I'm proposing.

> What format would long double have when compiling code in those 
> directories?

I'm proposing to build everything with IEEE long double except
the files that have to use IBM long double.  The new directory does not
change this.

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

If I'm understanding correctly, this would require #ifdef's in every file.
libm_alias_* are encapsulating this for you.  You can provide a single
implementation per directory (or many if you prefer #ifdef's in the header).

In your proposal, do you also think ldbl-128ibm functions should be renamed
to *ibm128?

I'm not against your suggestion, but I'm afraid it would require a lot more
code.  Does that make sense?

> 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

Exactly.  We tried that way.

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

Indeed. That's one of the reasons we created the new directory.

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

Exactly.  We're doing that.  We use the new directory to provide different
ldbl-128ibm-compat/libm-alias-ldouble.h and
ldbl-128ibm-compat/libm-alias-float128.h
  

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

> > Something else?  What other (existing) sysdeps directories for 
> > floating-point types would you propose to use in the sysdeps directory 
> > ordering?
> 
> I didn't understand your questions.
> ldbl-128ibm-compat is the only sysdeps directory I'm proposing.

My question was about which *existing* sysdeps directories are there (from 
the set {ldbl-128, ldbl-128ibm, float128}, in particular) (and what the 
order of all these directories is).

> If I'm understanding correctly, this would require #ifdef's in every file.
> libm_alias_* are encapsulating this for you.  You can provide a single
> implementation per directory (or many if you prefer #ifdef's in the header).

libm_alias_* are indeed intended to encapsulate #ifdefs so they aren't 
needed in every file, only in certain headers.  (Cf. how they've already 
replaced lots of #if conditionals on NO_LONG_DOUBLE and on whether to 
provide compat symbols, and so eliminated various files from ldbl-opt.)

> In your proposal, do you also think ldbl-128ibm functions should be renamed
> to *ibm128?

I don't see any *need* for such renaming (either adding extra exported 
function names for them, or renaming the source files).  If extra exported 
function names *are* added for them, I don't think that significantly 
affects my point that the type-generic template machinery shouldn't be 
used for such type-specific functions (because you can arrange for 
libm_alias_ldouble to add those aliases when those files are built with 
-mabi=ibmlongdouble and arrange for it to be used in ldbl-128ibm).

> I'm not against your suggestion, but I'm afraid it would require a lot more
> code.  Does that make sense?

I don't think it should require significantly more code to use 
libm_alias_* macros in place of type-generic ones (the type-generic ones 
largely wrap the libm_alias_* ones as far as possible anyway).

If you think things can't work without the type-generic machinery being 
used for this, I think you need to make the subsequent patches available 
somewhere and explain in more detail what the obstacles would be to making 
libm_alias_* work for them.

> > 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
> 
> Exactly.  We tried that way.
> 
> > (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).
> 
> Indeed. That's one of the reasons we created the new directory.

I suspect my suggestion of using __*ieee128 or similar for the exported 
names should avoid all the complications around __*f128 already existing.  
A new directory *is*, I expect, still needed for the few cases of 
functions in the long double API but not the _Float128 API (including e.g. 
new variants of nexttowardf and nexttoward that are needed for the new 
long double format).
  

Joseph Myers <joseph@codesourcery.com> writes:

> On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:
>
>> > Something else?  What other (existing) sysdeps directories for 
>> > floating-point types would you propose to use in the sysdeps directory 
>> > ordering?
>> 
>> I didn't understand your questions.
>> ldbl-128ibm-compat is the only sysdeps directory I'm proposing.
>
> My question was about which *existing* sysdeps directories are there (from 
> the set {ldbl-128, ldbl-128ibm, float128}, in particular) (and what the 
> order of all these directories is).

We're adding the new file on top of Implies:

ieee754/ldbl-128ibm-compat
ieee754/ldbl-128ibm
ieee754/ldbl-opt
ieee754/dbl-64
ieee754/flt-32
ieee754/float128

>> In your proposal, do you also think ldbl-128ibm functions should be renamed
>> to *ibm128?
>
> I don't see any *need* for such renaming (either adding extra exported 
> function names for them, or renaming the source files).  If extra exported 
> function names *are* added for them, I don't think that significantly 
> affects my point that the type-generic template machinery shouldn't be 
> used for such type-specific functions (because you can arrange for 
> libm_alias_ldouble to add those aliases when those files are built with 
> -mabi=ibmlongdouble and arrange for it to be used in ldbl-128ibm).

Agreed.

The question is: assuming you concluded you need new *ibm128 symbols,
should the changes affect everyone using ldbl-128ibm or just those using
ieee754/ldbl-128ibm-compat?
That's why we're using them.

>> I'm not against your suggestion, but I'm afraid it would require a lot more
>> code.  Does that make sense?
>
> I don't think it should require significantly more code to use 
> libm_alias_* macros in place of type-generic ones (the type-generic ones 
> largely wrap the libm_alias_* ones as far as possible anyway).

I was misunderstanding you.
Agreed.

> If you think things can't work without the type-generic machinery being 
> used for this, I think you need to make the subsequent patches available 
> somewhere and explain in more detail what the obstacles would be to making 
> libm_alias_* work for them.

OK.  That will have to wait a little more.

> I suspect my suggestion of using __*ieee128 or similar for the exported 
> names should avoid all the complications around __*f128 already existing.  
> A new directory *is*, I expect, still needed for the few cases of 
> functions in the long double API but not the _Float128 API (including e.g. 
> new variants of nexttowardf and nexttoward that are needed for the new 
> long double format).

OK.
I have to think more about this and go back to my notes.

Thanks!
  

Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> writes:

> Joseph Myers <joseph@codesourcery.com> writes:
>
>> I suspect my suggestion of using __*ieee128 or similar for the exported 
>> names should avoid all the complications around __*f128 already existing.  
>> A new directory *is*, I expect, still needed for the few cases of 
>> functions in the long double API but not the _Float128 API (including e.g. 
>> new variants of nexttowardf and nexttoward that are needed for the new 
>> long double format).
>
> OK.
> I have to think more about this and go back to my notes.

I'm still looking for this information.

I understand we don't have an agreement for all the usages I gave for this
macro, but we're using declare_mgen_finite_alias in math/e_scalb_template.c.

Is that a good reason to accept this patch?  :-)
  

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

> > I don't see any *need* for such renaming (either adding extra exported 
> > function names for them, or renaming the source files).  If extra exported 
> > function names *are* added for them, I don't think that significantly 
> > affects my point that the type-generic template machinery shouldn't be 
> > used for such type-specific functions (because you can arrange for 
> > libm_alias_ldouble to add those aliases when those files are built with 
> > -mabi=ibmlongdouble and arrange for it to be used in ldbl-128ibm).
> 
> Agreed.
> 
> The question is: assuming you concluded you need new *ibm128 symbols,
> should the changes affect everyone using ldbl-128ibm or just those using
> ieee754/ldbl-128ibm-compat?
> That's why we're using them.

They would (a) only affect ldbl-128ibm-compat (that is, configurations 
adding a third long double format), (b) only be for symbols that don't 
already have implementation-namespace exports (thus, not for __*l_finite 
or __issignalingl, for example), and (c) be implemented, generally, via 
changes to how libm_alias_ldouble macros are defined, and through the 
ldbl-128ibm functions being changed to use such macros, so most functions 
do not actually require wrappers in ldbl-128ibm-compat.
  

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

> Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> writes:
> 
> > Joseph Myers <joseph@codesourcery.com> writes:
> >
> >> I suspect my suggestion of using __*ieee128 or similar for the exported 
> >> names should avoid all the complications around __*f128 already existing.  
> >> A new directory *is*, I expect, still needed for the few cases of 
> >> functions in the long double API but not the _Float128 API (including e.g. 
> >> new variants of nexttowardf and nexttoward that are needed for the new 
> >> long double format).
> >
> > OK.
> > I have to think more about this and go back to my notes.
> 
> I'm still looking for this information.
> 
> I understand we don't have an agreement for all the usages I gave for this
> macro, but we're using declare_mgen_finite_alias in math/e_scalb_template.c.
> 
> Is that a good reason to accept this patch?  :-)

Maybe, depending on what the patches adding and using such a template (for 
a function that shouldn't exist at all for formats not supported for one 
of float / double / long double, but I assume the existing 
sysdeps/ieee754/float128/e_scalbf128.c takes care of the function not 
existing when float128 is not a supported long double format) look like.
  

Joseph Myers <joseph@codesourcery.com> writes:

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

>> > 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
>> 
>> Exactly.  We tried that way.
>> 
>> > (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).
>> 
>> Indeed. That's one of the reasons we created the new directory.
>
> I suspect my suggestion of using __*ieee128 or similar for the exported 
> names should avoid all the complications around __*f128 already existing.  
> A new directory *is*, I expect, still needed for the few cases of 
> functions in the long double API but not the _Float128 API (including e.g. 
> new variants of nexttowardf and nexttoward that are needed for the new 
> long double format).

When you say that a namespace is clean, are you saying that new symbols should
only be created as required?  e.g.  __cosieee128 should not exist because there
is already __cosf128.
  

On Tue, 15 May 2018, Tulio Magno Quites Machado Filho wrote:

> >> > (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).
> >> 
> >> Indeed. That's one of the reasons we created the new directory.
> >
> > I suspect my suggestion of using __*ieee128 or similar for the exported 
> > names should avoid all the complications around __*f128 already existing.  
> > A new directory *is*, I expect, still needed for the few cases of 
> > functions in the long double API but not the _Float128 API (including e.g. 
> > new variants of nexttowardf and nexttoward that are needed for the new 
> > long double format).
> 
> When you say that a namespace is clean, are you saying that new symbols should
> only be created as required?  e.g.  __cosieee128 should not exist because there
> is already __cosf128.

No, I'm not saying this.

1. The namespace issue is that C11 doesn't reserve the name cosf128, so 
just redirecting cosl to cosf128 wouldn't be namespace-clean for that 
reason.

2. __cosf128 and __cosieee128 are both reserved.  Now, we don't generally 
want multiple reserved-namespace names *pointing to the same function* 
exported from glibc - that makes the dynamic symbol table in the installed 
shared libraries larger than necessary.  So we don't want any new 
__issignalingieee128, for example, because __issignalingf128 is fully 
sufficient whether the type is called _Float128 or long double.  But 
__cosf128 is a purely internal symbol.  So exporting __cosieee128 would 
not mean redundant reserved-namespace exports - and would avoid 
complications around some functions already having an internal __*f128 
name, some not having it, and some such internal names, where they exist, 
having the *f128 alias point to them, while others have the *f128 alias 
point to a wrapper.  It would also, I expect, avoid the need to have new 
*l versions for the binary128 functions, and thus to have new __*ibm128 
exports, so reducing the total number of exports needed.

(If you wanted to support users declaring *l functions directly without 
including <math.h> - which of course doesn't work at present with 
-mlong-double-64 - you'd need some other mechanism for achieving the 
redirections, as a plain *l call with no redirection will end up at the 
default symbol version for that function.)