Re: On inlining in C++

[Geoff Keating <geoffk at geoffk dot org>]

Joe Buck <jbuck@synopsys.com> writes:

> On Mon, Aug 04, 2003 at 12:35:48PM -0400, Robert Dewar wrote:
> > > Excellent article.  I think that anyone who wishes to oppose the argument
> > > should be asked to demonstrate that we can get better quality of results
> > > by deviating from the simple approach Gaby describes; philosophical
> > > arguments should not suffice.
> > 
> > Well there is a burden of demonstration on both sides I would say, in terms
> > of showing behavior on actual code.
> 
> Don't forget that the biggest complaint we have about GCC is how slow the
> compiler is.  Ignoring or partially ignoring "inline", and doing analysis
> instead, costs time.
> 
> I suggest resolving this argument by doing an experiment.
> 
> Option 1: a version of GNU C++ that
> 
> * honors the "inline" keyword in all situations where the compiler is
>   capable of inlining the call
> * does the same for functions defined in the class body
> * when -Winline is given, issues a warning and explanation about why
>   a call is not inlined
> * avoids computing any metrics related to inlining decisions (unless -O3)
> 
> Option 2: a version of GNU C++ that uses the smartest heuristics that the
> "ignore inline" advocates can come up with.

I completely agree.

However, I claim that option (2) will always win or tie.  Why?
Because you can always use heuristics that are "inline exactly when
option (1) would have inlined".

In fact, I will go further, and claim that option (2) will win.
Saying that option (2) will tie is equivalent to saying that every
case of inlining triggered by option (1) is neutral or good for
performance, and I know that this is not true.  You can start by
rejecting cases that cannot possibly be good for performance.

> Now, build a lot of C++ code with -O2 for both options.  Measure compiler
> speed as well as speed and space of the final code.  If option 2 is
> consistently better, I surrender.  If option 2 is better only for one or
> two programs, and it turns out that these programs use "inline" in
> inappropriate ways, then the programs should be fixed.

Don't forget to test on multiple targets!

-- 
- Geoffrey Keating <geoffk@geoffk.org>