[patch] inline __getreent in newlib
Fri Sep 7 00:15:00 GMT 2007
On Thu, Sep 06, 2007 at 04:38:04PM -0700, Brian Dessent wrote:
>I noticed today that all instances of _REENT in newlib go through a
>function call to __getreent(). All this function does is get the value
>of %fs:4 and subtract a fixed offset from it, so this seems rather
>wasteful. And we already have the required value of this offset
>computed for us in tlsoffsets.h, so we have everything we need to
>provide newlib with an inline version of this function, saving the
>overhead of a function call. It would obviously be cleaner to be able
>#define __getreent() (&_my_tls.local_clib)
>...however this would require dragging all kinds of internal Cygwin
>definitions into a newlib header and since we already have the required
>offset in tlsoffsets.h we might as well just use that. The attached
>patch does this; the second part would obviously have to be approved by
>the newlib maintainers, but I thought I'd see if there's any interest in
>this idea first before bothering them.
>I don't pretend to claim that this is a very scientific benchmark at
>all, but there does seem to be a slight improvement especially in the
>getc column which represents reading the whole 16MB file one byte at a
>time, where this _REENT overhead would be most pronounced.
>So, valid optimization or just complication?
>2007-09-06 Brian Dessent <firstname.lastname@example.org>
> * include/cygwin/config.h (__getreent): Define inline version.
I've always meant to investigate some way to turn the reent stuff into
a macro in the newlib library after doing that for cygwin. I'm not
wild about using offsets like this but I can't think of any other way
to do it which didn't have the problems that you describe.
So, I guess I'll come down on the side of speed over clarity. I'm sure
that Jeff won't mind your checking in the undef in newlib. So, please
check in everything but, again, document heavily what you're doing with
the reent macro.
More information about the Cygwin-patches