Re: [RFC] Support for type-generic libm function implementations libm

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

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.