This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Support for type-generic libm function implementations libm
- From: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 14 Jun 2016 17:59:21 -0500
- Subject: Re: [RFC] Support for type-generic libm function implementations libm
- Authentication-results: sourceware.org; auth=none
- References: <55807bea-73b6-2b68-df1d-bf94b841be49 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606142108030 dot 10937 at digraph dot polyomino dot org dot uk>
On 06/14/2016 04:20 PM, Joseph Myers wrote:
> On Tue, 14 Jun 2016, Paul E. Murphy wrote:
>
>> This builds from https://sourceware.org/ml/libc-alpha/2016-06/msg00550.html
>> to further tweak the math Makefile.
>>
>> As it stands, there is much duplication when building
>> wrappers for IEEE functions and complex functions.
>> With a little creativity, this can reduce much
>> redundant source, and simplify supporting new types.
>>
>> Only two platforms (alpha and m68k) override complex
>> functions. Both should work with the approach.
>
> What about the ldbl-opt code that wraps complex functions? Does that need
> updating?
My current understanding is that ldbl-opt is fairly self contained,
and builds its interesting bits more or less independently of the
math makefile. Irrespective, the patch still needs more work
in fundamental areas.
>
>> This defines two new classes of libm objects. g for
>> generated objects, and t for templates to generate
>> those objects.
>
> Note that right now t_* is used in libm for generated tables....
>
>> Note, I have not tested this on alpha. If anyone can
>> assist me in testing (or just point out a reasonable
>> mechanism to do it myself) it would be much
>> appreciated. Likewise for m68k.
>
> I don't really like how platforms needing to override a file have to
> override the template file with something containing conditionals on the
> type. Is it hard to arrange things so that: if an appropriately named
> file with a name depending on the type is present in sysdeps, that file is
> used instead of the template (so compiling from a per-type file in sysdeps
> takes precedence over compiling from the template)?
That is indeed one of the drawbacks. One thought might be to have
such platforms add a fragment declaring what they override. I.e
libm-gen-call-overrides = g_cargf
and the obviously incorrect, but handwavy change to patchup libm-calls:
libm-calls = $(filter-out $(libm-gen-call-overrides), $(libm-calls)) \
$(libm-gen-call-overrides:g_%=s_%))
Though, such blatantly goes against the desirable ability to
quietly override common files. This is an area where I
welcome feedback from the glibc makefile experts. There is
much subtlety.
>
> On whatever platforms you have tested, did you make sure the installed
> stripped shared libraries were unchanged (or at least that the relevant
> objects were after stripping debug info, if the changes have the effect of
> changing the order in which objects are linked into libm.so)?
I've been working this out and running the tests on x86_64. The intent
is these changes *should* be generic. I've only verified the the correct
flavor of atan is called. More complex wrappers deserve more inspection.
Perhaps adding a few extra test cases is a better way to catch unwanted
silent conversions.
The Makefile changes are not trivial. Thus, I'd like feedback on what
I'm doing wrong sooner, rather than later.
>
>> +#if M_TYPE == M_FLOAT
>> +# define M_PFX FLT
>> +# define M_LIT f
>> +# define M_SUF(c) c ## f
>> +# define FLOAT float
>> +#elif M_TYPE == M_DOUBLE
>> +# define M_PFX DBL
>> +# define M_LIT
>> +# define M_SUF(c) c
>> +# define FLOAT double
>> +#elif M_TYPE == M_LDOUBLE
>> +# define M_PFX LDBL
>> +# define M_LIT L
>> +# define M_SUF(c) c ## l
>> +# define FLOAT long double
>> +#else
>> +# error Error: M_TYPE must be defined before including
>> +#endif
>
> I'd expect more macros making use of M_PFX, M_LIT - are those intended to
> be added as needed? I'd also expect macros relating to use of M_*
> constants from <math.h>. Probably the undefine / redefine of LDBL_EPSILON
> for IBM long double also belongs in this header.
Yes, they would only be added as needed.
>
>> +FLOAT
>> +M_SUF (__carg) (__complex__ FLOAT x)
>
> You can't use __complex__ FLOAT because that won't work with __float128
> (as it's a built-in typedef not a keyword; GCC bug 32187). Instead, you
> need another macro for the complex type.
That is indeed annoying.