On inlining in C++

[Daniel Berlin]

On Mon, 4 Aug 2003, Joe Buck wrote:

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

Most good compilers don't do either Option 1 or Option 2, they do a
combination like so:

Honor inline except when not possible
Perform analysis and use heuristics to determine what non-inline
functions to inline.

The time taken by doing the necessary analysis for inlining decisions is
not as high as you seem to think, because most of the same analysis
(callgraph construction, etc) is required for other things we want to do
anyway.

Certainly, right now, we inline when we should partially inline or clone,
assuming we have the necessary profile info or estimate it.

But, as an example, Intel's compiler does the following when not given
profile information:

"If you do not use profile-guided optimizations with -ip or -ipo, the
compiler uses less aggressive inlining heuristics:

Inline a function if the inline expansion will not increase the size of
the final program.

Inline a function if it is declared with the inline or __inline keywords.
"

Note that is still a combination of your option 1 and 2, becuase it does
inlining for functions not declared inline.