Re: issues with inlining

[Michel LESPINASSE <walken at zoy dot org>]

On Thu, Jan 09, 2003 at 07:46:25PM +0000, Andrew Haley wrote:
>>> 2) g++ 3.2.1 seems to totally ignore the inline keyword
>>>    and do as it pleases when being used with -O3.  
>>>    Unfortunately, I know better than the compiler what
>>>    should be inlined - so, ignoring the inline keyword
>>>    and inlining other functions results in much slower
>>>    code.
> 
> According to the docs
> 
>      `-O3' turns on all optimizations specified by `-O2' and also
>      turns on the `inline-functions' option.
> 
> so why are you using -O3 if you want to control inlining by means of
> the "inline" kwyword?

there are two issues here:
* compiler using inlining when we don't specify the inline keyword:
  you're totally right here, this is what -O3 does and we have no
  right to complain about it
* compiler *not* using inlining even though we use the inline keyword:
  I think this is an issue. You can work around it by using
  always_inline but it's not backwards compatible with other gcc
  versions and it's nontrivial to write an autoconf test for it.

>>> 4) The instruction limit that can be set with -finline-limit
>>>    seems to count instructions before optimization...
>
> True -- the inliner works at the source level before optimization is
> performed.  This is the best way to do it.

You're most probably right on average. But you sometimes see code that
use compile-time constants for specialization, i.e. one big inline
routine that evaluates to something small based on the value of some
constant parameters. In this case, the fact the inliner only sees the
huge initial routine instead of the smaller one after specialization,
combined with the fact the programmer can not use the inline keyword
to force inlining, is an issue.

Cheers,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.