This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:


Steve Ellcey

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]