This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC performance regression - up to 20% ?
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: Michel LESPINASSE <walken at zoy dot org>
- Cc: Andreas Jaeger <aj at suse dot de>, Jan Hubicka <jh at suse dot cz>, gcc list <gcc at gcc dot gnu dot org>
- Date: Mon, 22 Apr 2002 20:49:20 -0400
- Subject: Re: GCC performance regression - up to 20% ?
On Monday, April 22, 2002, at 08:39 , Michel LESPINASSE wrote:
> On Mon, Apr 22, 2002 at 09:10:55AM +0200, Andreas Jaeger wrote:
>> You might want to use the always_inline function attribute for your
>> inline functions in 3.1. It makes the inlining unconditional.
>
> Thanks, that suggestion does solve my inlining problem. I think the
> documentation for this option is a bit confusing: it says "For
> functions declared inline, this attribute inlines the function even if
> no optimization level was specified." which is true I guess, but the
> documentation does not mention that when optimization is enabled gcc
> will not always inline functions declared inline, unless we use this
> attribute.
I think the problem is that part of documentation was written before the
part about always_inline.
>
> Also I want to point out that this is a new behaviour, as gcc up to
> 3.0.4 apparently always inlined functions declared inline (when
> compiling with -O2 at least).
Not really new `behavior' was just the inline limit was lowered in 3.0
and above.
>
> I think either the documentation of always_inline should be made more
> clear, or the inline keyword should be made to behave like
> always_inline when optimizing with -O2 and above (as it did previously).
the inline keyword was always just an hint to the compiler in ISO C++
and ISO C.
And it was -O3 that included the inline optimization.
Thanks,
Andrew Pinski
>
> --
> Michel "Walken" LESPINASSE
> Is this the best that god can do ? Then I'm not impressed.
>
>