This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Move declare_mgen_finite_alias definition
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
--
Tulio Magno