Export fast *rint* functions
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