[PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES

[Zack Weinberg]

Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, May 25, 2004 at 10:42:52AM -0700, Zack Weinberg wrote:
>> Ulrich Drepper <drepper@redhat.com> writes:
>> 
>> > Zack Weinberg wrote:
>> >
>> >> Go away and prove to me glibc isn't broken.  Then we can talk.
>> >
>> > I'm not the one who wants to change glibc. 
>> 
>> I'm not the one who's been refusing to post numbers since 1998.
>
> And your numbers are where?
> I did some benchmarking more than 2 years ago and the functions which were
> in GCC handled better or as good as in glibc were changed in string2.h.
> See http://sources.redhat.com/ml/libc-hacker/2001-11/msg00035.html and
> http://sources.redhat.com/ml/libc-hacker/2002-01/msg00091.html

I should be clear that I don't care about microbenchmarks; I care only
about overall application performance and text size.  Many of the
optimizations in string2.h are a win on microbenchmarks but a lose on
anything else because they bulk up the text size in exchange for less
than 1% overall performance improvement.

You do have to go back a long ways to find the severe problems with
the string inlines - perhaps some have been improved since then, or
perhaps the compiler has gotten better at optimizing around them.
Here's one: http://sources.redhat.com/ml/libc-alpha/2000-10/msg00349.html
More recently: http://sources.redhat.com/ml/libc-alpha/2003-12/msg00182.html
And, to be fair, I also found this message from 2003 where
disabling string inlines increased the text size of cc1 by 1.5KB:
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01302.html

I am sorry to report that I cannot find the message I remember sending
in 1998.  My memory of it is that I observed string inlines to cause
100% (yes, 100%) code size expansion in the standalone cpp, with no
measurable performance difference.  It was probably private mail to
Ulrich.

Math functions, gcc didn't used to do so well, but Kaveh reported a
30% speedup on one benchmark from -D__NO_MATH_INLINES, in April of
this year: http://gcc.gnu.org/ml/gcc/2004-04/msg00842.html

> b) e.g. strcspn.c below in x86-64 (glibc inline is 30% faster than gcc
>    builtin)
> c) strtok/strsep/strdup/strndup not handled at all by GCC

These are all functions where I would expect an inline to be a win on
a microbenchmark but a net lose in general.  With strcspn and similar
functions, the optimization available is the selection of an 1c/2c/3c
variant.  That *is* a worthwhile optimization, but it comes at the
cost of injecting a big block of code into each caller.  I would
seriously consider taking the 1c/2c/3c variants out-of-line and using
the macro just to do the selection.  GCC could then be taught to do
that optimization.

For str(n)dup I don't see the point _at all_; the operation is totally
dominated by the time to do malloc and memcpy.  Inlining the body of
str(n)dup does nothing but increase text size.  Where the argument is
constant, it *would* be a win to transform strdup("blah") to
memdup("blah", 5), and strndup("blah", X) to memdup("blah", MIN(X, 5)),
avoiding the strlen ... but that is *not* what string2.h does.

----

If the only concerns were the ones covered so far, I would take the
position that we should disable specific transformations as gcc
becomes able to do them better, or as they are demonstrated to be
non-optimizations.  However, there are two other concerns.  Disabling
things one-by-one unilaterally from gcc's side requires fixincludes
hacks, which we would prefer to avoid to the maximum extent possible.
And glibc development has not historically wanted to cooperate with us
much (with bad blood on both sides of the fence); nor does there
appear to be a release schedule for glibc, nor any other way for us to
coordinate use of updated glibc with updated gcc.  These, to my mind,
speak very strongly indeed for accepting Giovanni's patch now (thus
there is no need for coordination or for fixincludes hacks) and then
improving gcc's builtins as appropriate.

zw