This is the mail archive of the
mailing list for the glibc project.
Proposal: Remove or reduce math-finite.h
- From: Steve Ellcey <sellcey at marvell dot com>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 19 Mar 2019 21:27:00 +0000
- Subject: Proposal: Remove or reduce math-finite.h
I would like to start a new thread to discuss a proposal that Wilco Dijkstra
brought up in a different thread. Mainly, the idea of getting rid of
This header uses an asm attribute so that C/C++ programs compiled with -Ofast
will call functions like __acosh_finite instead of acosh. acosh would be a
wrapper that would check for some special conditions and then call
__acosh_finite. The asm attribute means that compiling with -Ofast would
result in a call directly to __acosh_finite instead of going through the
acosh wrapper function.
For some of the functions in this file; pow, powf, log, logf, log2, log2f,
exp, expf, exp2, and exp2f; the default implementations have been improved
to handle the special cases and the *_finite names are just aliases of the
normal name and so the asm attribute isn't accompishing anything.
Some of these functions have specialized versions for different platforms
and I haven't verified that all of those also don't need the *_finite
wrappers, but I believe that that is probably the case. I can verify
that if we want to proceed with a change.
So my main question is: What do people think about two possible proposals:
1) Get rid of math-finite entirely. For functions where *_finite is an
alias of the normal routine there would be no noticable change, for
other cases, when compiling with -Ofast, there may be a slight slowdown
because we would now go through the wrapper that we used to avoid.
2) Just get rid of the entries for the 10 functions that are not needed
for the generic implementations and verify that they also are not needed
for any specialized implementations. This should have no affect assuming
that none of the specialized implementations use wrappers.
My motivation for wanting to do this (in addition to cleaning things up)
involves the libmvec function naming scheme and calling convention.
See the discussion at: