Re: On inlining in C++

[Thomas Kunert <kunert at physik dot tu-dresden dot de>]

Mike Stump wrote:
> On Monday, August 4, 2003, at 09:31 AM, Joe Buck wrote:
>
> > On Mon, Aug 04, 2003 at 03:06:43PM +0200, Gabriel Dos Reis wrote:
> >
> > >       Give C++ "inline" its original and obvious meaning
> > >
> > >          Gabriel Dos Reis <gdr@integrable-solutions>
> >
> >
> > Excellent article.
>
>
> This is a complete waste of time.  inlining is an optimization.  
> Optimizations are always subject to improvement.  Therefore, inlining is 
> subject to improvement.
>
> Removing the optimizer from inlining isn't where we are going, it just 
> isn't going to happen, ever, get over it.
>
> What isn't a waste of time, would be to point out a case where the 
> optimizer gets it wrong, and explain what would be better, and then we 
> can retune the optimizer to be _better_ without that being at the 
> expense of other code.  We already knew that some of the heuristics are 
> probably wrong for C.  If people want, we can bump up the numbers a ton 
> for the heuristic for things marked with inline (or whatever else anyone 
> would like) and then wait for the bug reports that said we went too far, 
> and then bump them back down some...
>
> It would be good if we could sign up lots of people to benchmark their 
> favorite programs as we tune it around, and give timely feedback on them 
> so that we know how things are being impacted.

As a C++ programmer I would like to ask you to retain a mechanism to tell
the compiler "Inline at least everything I marked as inline." Currently,
this mechanism is -finline-limit=1000000.

Correct decisions about efficient inlining depend on many parameters the
compiler does not know, e.g.

- How much time takes one call of the function. This time in general depends
on the actual parameters and cannot be guessed by the compiler.

- How much total time does the code spent in the function. If this time is
only a few micro seconds, there is absolutely no point in inlining.

- From how many places the function is being called throughout the program.

- How often the function is called from a certain position.

The programmer has the complete picture. He has an idea about the actual
parameters passed to the function. He can actually measure the time.
He knows if some function is critical or not.

Maybe someday in the distant future compilers are smart enough to find out
these things. But currently I strongly prefer to control inlining myself,
because in most cases I know better. The compiler should be allowed to
overrule my decision only if it can prove me wrong.

Thanks,
Thomas Kunert