[RFC] pthread_once: Use unified variant instead of custom x86_64/i386
Rich Felker
dalias@libc.org
Mon Oct 20 03:41:00 GMT 2014
On Sun, Oct 19, 2014 at 06:37:16PM -0700, Roland McGrath wrote:
> > +static int
> > +__attribute__((noinline))
>
> Space before paren.
>
> > +__pthread_once_slow (pthread_once_t *once_control, void (*init_routine) (void))
>
> This needs a comment explaining why it's separate. I would have expected
> the compiler to generate essentially the same code for the early bailout
> case marked with __glibc_likely.
Sadly gcc never does that, as far as I know. This optimization
shouldn't even be dependent on whether the code path is "likely" or
not; compilers should "shrink-wrap" code paths that don't need heavy
stack frame setup whenever they can do so without pessimizing the
other code paths, but they don't.
The method in this patch is the standard fix that I've used in various
places to "manually shrink-wrap" before and it seems appropriate here.
I just tried the same approach in musl for pthread_once (already using
it for mutexes) and it doubled performance in the fast path, so I
think it's a good idea.
Rich
More information about the Libc-alpha
mailing list