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


Jakub Jelinek <jakub@redhat.com> writes:

> 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.

That requires either fixincludes goo, or a new version of glibc,
neither of which is ideal.

> 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.

How are you defining "good enough"?  We should not slavishly copy
every optimization out of glibc's headers.  Many of them were added
without due care and consideration, and actually produce worse code.
I have been saying this for years: defining __NO_STRING_INLINES
reliably produces smaller, faster code, even before string
optimizations started getting added to GCC.  Don't have data for
__NO_MATH_INLINES but would be surprised if it were different.

My inclination is to approve Giovanni's patch and then work on adding
back ONLY those optimizations that can be demonstrated with hard
numbers to actually be optimizations.

zw


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