issues with inlining

issues with inlining

[Carlo Wood]

Imho there are serious problems with inlining and gcc 3.x.

As most of you know, I am not a compiler hacker, but
extensively using the compiler for every day development
of C++ libraries and recently I've laid my eyes on optimization
issues (needing fast code and all).

The inlining problems exist of functions not being inlined
that should have been inlined, and others getting inlined
while they would better not have been inlined.

The following problems have been spotted:

1) -Winline doesn't give me a warning when a function is
   not inlined, even while I am using the inline keyword
   for it.
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.
3) Apparently gcc is still inlining "top down", meaning
   that when a() calls b() which calls c() which calls d(),
   then b() is inlined into a(), c() is inlined into
   d() and when then the function becomes too big, it
   stops.  THIS IS HORRIBLE!!!  This *definitely* needs
   to be changed into that d() is inlined into c(),
   and if the function isn't getting too big, then c()
   into b() etc.
4) The instruction limit that can be set with -finline-limit
   seems to count instructions before optimization...
   This means that I need to give a limit of 8000 instructions
   before everything is inlined - although after optimization
   hardly anything is left (maybe 50 to 100 instructions, way
   below the default 600 threshold).
   By the time I get my inner functions inlined this way,
   EVERYTHING is inlined (I get one big function call of
   120,000 instructions :/ (after compiling 60 minutes)).

The reason for this functionality failure is imho related
to templates: With C++ templates it happens that more and
more code is available at the same time, unlike for C code.
Code with lots and lots of templates (like my code) exists
often for 95% of header files.  That makes it increasingly
important for the compiler to start inlining "bottom up",
and to honour 'inline' keywords by giving them a high priority.

-- 
Carlo Wood <carlo@alinoe.com>

Re: issues with inlining

[Michel LESPINASSE]

Hi Carlo,

On Thu, Dec 19, 2002 at 02:22:12AM +0100, Carlo Wood wrote:
> The following problems have been spotted:

[quoted below]

Did you get any replies to your email ? I've complained about just the
same issues previously without much success... issues 1) and 2) being
the most important for me.

Cheers,

> 1) -Winline doesn't give me a warning when a function is
>    not inlined, even while I am using the inline keyword
>    for it.
> 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.
> 3) Apparently gcc is still inlining "top down", meaning
>    that when a() calls b() which calls c() which calls d(),
>    then b() is inlined into a(), c() is inlined into
>    d() and when then the function becomes too big, it
>    stops.  THIS IS HORRIBLE!!!  This *definitely* needs
>    to be changed into that d() is inlined into c(),
>    and if the function isn't getting too big, then c()
>    into b() etc.
> 4) The instruction limit that can be set with -finline-limit
>    seems to count instructions before optimization...
>    This means that I need to give a limit of 8000 instructions
>    before everything is inlined - although after optimization
>    hardly anything is left (maybe 50 to 100 instructions, way
>    below the default 600 threshold).
>    By the time I get my inner functions inlined this way,
>    EVERYTHING is inlined (I get one big function call of
>    120,000 instructions :/ (after compiling 60 minutes)).

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

Re: issues with inlining

[Andrew Haley]

Michel LESPINASSE writes:
 > Hi Carlo,
 > 
 > On Thu, Dec 19, 2002 at 02:22:12AM +0100, Carlo Wood wrote:
 > > The following problems have been spotted:
 > 
 > [quoted below]
 > 
 > Did you get any replies to your email ? I've complained about just the
 > same issues previously without much success... issues 1) and 2) being
 > the most important for me.

 > 
 > Cheers,
 > 
 > > 1) -Winline doesn't give me a warning when a function is
 > >    not inlined, even while I am using the inline keyword
 > >    for it.
 > > 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?

 > > 3) Apparently gcc is still inlining "top down", meaning
 > >    that when a() calls b() which calls c() which calls d(),
 > >    then b() is inlined into a(), c() is inlined into
 > >    d() and when then the function becomes too big, it
 > >    stops.  THIS IS HORRIBLE!!!  This *definitely* needs
 > >    to be changed into that d() is inlined into c(),
 > >    and if the function isn't getting too big, then c()
 > >    into b() etc.

We're working on 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.

Andrew.

Re: issues with inlining

[Michel LESPINASSE]

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.

Re: issues with inlining

[Carlo Wood]

On Thu, Jan 09, 2003 at 01:50:02PM -0800, Michel LESPINASSE wrote:
> > According to the docs
> > 
> >      `-O3' turns on all optimizations specified by `-O2' and also
> >      turns on the `inline-functions' option.

But that says nothing about priority regulation.

> > so why are you using -O3 if you want to control inlining by means of
> > the "inline" kwyword?

To let the compiler decide is MORE can be inlined than what I already
marked as must-be-inlined (although it doesn't do that :/).

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

Of course it is best to FIRST inline and THEN optimize - but, the set
instruction limit should be on the optimized result, not on on the
number of instructions before optimization.

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

Exactly my point.  I use HUGE template functions that go like:

  if (constant == 1)
  {
    ...
  }
  else if (constant == 2)
  {
    ...
  }
  
  etc etc.  We talk about a reduction of 100 in size ONLY because
  of if (CONSTANT) { } constructs.  The -finline-limit is really 
  un usable when it doesn't ignore the instructions in those
  blocks that will not be used.  Note that even with -O0 these
  blocks are removed... so why the need to count those instruction
  when deciding whether or not to inline the function?!

-- 
Carlo Wood <carlo@alinoe.com>

Re: issues with inlining

[Alexandre Oliva]

On Jan  9, 2003, Carlo Wood <carlo@alinoe.com> wrote:

> To let the compiler decide is MORE can be inlined than what I already
> marked as must-be-inlined (although it doesn't do that :/).

If you expect the inline keyword to accomplish this, check your
assumptions.  That's not the meaning of `inline' in any Standard I've
ever seen.

-finline-all-functions (implied by -O3) behaves as if every single
function has been declared as inline.  If you use one of this options,
you get what you asked for.

> Of course it is best to FIRST inline and THEN optimize - but, the set
> instruction limit should be on the optimized result, not on on the
> number of instructions before optimization.

How about your contributing this time-machine algorithm you seem to
have come up with? :-)

>   Note that even with -O0 these blocks are removed... so why the
>   need to count those instruction when deciding whether or not to
>   inline the function?!

Because we don't do many optimizations on trees yet.  As we move
optimization passes from RTL to trees, before function inlining, this
should improve.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: issues with inlining

[Diego Novillo]

On Sun, 19 Jan 2003, Alexandre Oliva wrote:

> >   Note that even with -O0 these blocks are removed... so why the
> >   need to count those instruction when deciding whether or not to
> >   inline the function?!
> 
> Because we don't do many optimizations on trees yet.  As we move
> optimization passes from RTL to trees, before function inlining, this
> should improve.
> 
Right now, the tree optimizers are run after inlining has taken
place.  This is convenient for us because we still can't do
IPA properly.  Long term we should teach the tree optimizers
to work across procedures, but that is still a ways off.


Diego.