Re: On inlining in C++

[Joe Buck <jbuck at synopsys dot com>]

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.

Part of the work for the experiment is to have a libstdc++ that is
as nearly clean with respect to -Winline (without resorting to suppressing
messages from system headers) as it can be made.

The switch between the two modes can be done by a flag, an ifdef,
whatever.  I don't care, because I suspect we'll wind up shipping only one
choice.

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.

My prediction is that option 1 will be better by every measure (though the
compile time difference may be small).