This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES


On Tue, May 25, 2004 at 11:44:22AM +0200, Giovanni Bajo wrote:
> this patch adds two new builtin defines on linux systems: __NO_MATH_INLINES and
> __NO_STRING_INLINES. These defines disable the inline assembly version of
> standard library functions in glibc, which conflict with the GCC builtins for
> the same functions.
> 
> This is known to positively affect speed on many testcases: see for instance
> http://gcc.gnu.org/ml/gcc/2004-04/msg00840.html. On the other hand, it might
> well be that we are still missing optimized builtins for some functions for
> which we are going to lose a fast assembly optimized version.
> 
> Given that:
> 
> * We are still in Stage 1, there is tons of time to test the mainline, spot
> testcases which are affected negatively by this change, and fix them properly
> by implementing the missing builtins.
> * The correct way to operate for the present and the future is to use GCC
> builtins for anything for which it would make sense to provide an inline
> version in glibc.
> * In the worst scenario, the patch could even be pretty easily reverted on the
> branch a few days before release without many troubles, if critical
> show-stopper regressions were found that nobody had time to fix properly.
> 
> I'm positive that this patch is an absolute step forward.
> 
> This has been bootstrapped and tested (all languages) on i686-pc-linux-gnu with
> no new regressions. OK for mainline?

I disagree.
Instead, the inlines should be disabled one by one as soon as GCC has
comparable or better support for the particular function, by adding
#if !__GNUC_PREREQ (3,5) (or whatever else the first GCC version that
has good enough support for it will be) around it.
Current <bits/string2.h> has already several !__GNUC_PREREQ (3, 0) and similar
#ifs around (e.g. strcpy, strstr, ...).
E.g. in the area of math inlines, GCC has these days many builtins, but many
of them don't do anything special appart from special casing some constant
arguments.
Last time I started looking into it (two months ago?), less than half of the
functions I looked at were good enough in GCC to remove the inline in
mathinlines.h.
>From <bits/string2.h>, see e.g. strcmp on IA-64 (well, almost anything but
IA-32/x86-64):
#include <string.h>
int foo (const char *p) { return __builtin_strcmp (p, "a"); }
int bar (const char *p) { return strcmp (p, "a"); }
Similarly strncmp.  strcspn/strspn/strpbrk might be worth inlining for short
second arguments, at least under -O3 or -minline-all-stringops.
strtok/strsep/strdup/strndup not handled at all.
I'm not arguing that GCC does a good job with many functions (and for many
it does a better job than glibc).  But it IMNSHO needs to be changed on a
case by case basis after studying the particular function.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]