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: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 15 Jun 2016 01:09:50 +0000
- 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> <533193d2-cdb7-7da6-88c3-84cc6481a041 at linux dot vnet dot ibm dot com>
On Tue, 14 Jun 2016, Paul E. Murphy wrote:
> > 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.
Well, it includes files carg.c and cargl.c, for example, both of which
include the corresponding math/ files and do other things before or after
that inclusion.
> > 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.
My point is that as a general principle, certain sorts of cleanup patches
are expected not to change the generated code, and if your patch is one of
them, you should do the comparison, and have an explanation for any
differences found so we can see if they are harmless. (For example, there
might be differences because the existing files are unintentionally out of
sync, or float files are accidentally using double operations at present,
or if there's inconsistency in how M_* constants are used in float files
that it doesn't make sense to replicate when making them type-generic. I
don't know if there are such issues at present, but those would be
plausible reasons for making a function type-generic changing the code
generated for it.)
--
Joseph S. Myers
joseph@codesourcery.com