Export fast *rint* functions

Dave Korn dave.korn@artimi.com
Sat Dec 29 17:57:00 GMT 2007

On 29 December 2007 17:30, Christopher Faylor wrote:

> On Sat, Dec 29, 2007 at 05:22:31PM -0000, Dave Korn wrote:
>> On 29 December 2007 17:04, Christopher Faylor wrote:
>>> I assume that the above comment about aliasing needs to know right?
>>  Sorry, can't parse that.  ENOCOFFEE?  ;-)
> I meant "go" above.  I got distracted by my stupid turtle who, after
> twelve years of docility in the tank behind me, has decided to spend the
> last two months frantically trying to claw his way out of his tank.
> I guess I just don't understand what the aliasing is all about here.

  Right, it goes like this:

-  At the moment, all the new x87 *rint* functions are implemented as fast
math variants in newlib, with '_f_' prefixes to the function names.  (I'm not
convinced this is necessarily correct, but that's the way it is right now;
when Jeff gets back I'll discuss whether and why they can or can't be
considered first-class implementations).

-  For the functions that didn't already exist (i.e., all except
rint/rintf/lrint/lrintf), Jeff added wrappers using the POSIX standard names
that call through to the equivalent _f_ hard-fp version of the same function.

  Now, these wrappers are fairly superfluous.  They set up a stack frame,
immediately tear it down, then tail-call to the underlying _f_ function.

  So, I figured, if someone's linking against the DLL and needs one of these
functions, why not get the link to resolve directly to the _f_ function and
avoid the wrapper?  It won't make a great deal of impact to debuggability or
stack traces and it saves a few wasted instructions.

  Also, the existing soft-float implementations of rint/rintf/lrint/lrintf are
still present in newlib; they are not overridden by the _f_ versions.  So any
app that links against these will continue to get the old slow soft float
version.  By exporting the _f_ version with the name of the non-_f_ version,
apps will link against the hard fp version instead.

  OTOH, I can see how this could be a bit confusing and make setting
breakpoints a bit tricky.  I could remove the aliasing for the new functions
and make calls go through the wrapper, but there aren't any wrappers for the
existing functions, just soft-float implementations, so at least those
functions would still need to be aliased to the _f_ versions.  Long-term, my
plan is to either provide wrappers for those existing functions (in a
cygwin-only patch to newlib), or if there are no compliance problems to
promote all the _f_*rint* functions to first-class versions, losing the _f_
prefix and wrapper altogether.

Can't think of a witty .sigline today....

More information about the Cygwin-patches mailing list