Re: Problems with stepanov and inlining on the main line

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article
<Pine.LNX.4.21.0108061850320.17030-100000@snake.iap.physik.tu-darmstadt.de>
Peter Schmid writes:

> Function inlining seems to cause a huge pessimisation for the current 3.1
> g++ compiler on the i686-pc-linux-gnu target. The abstraction penalty
> is 7.4 in contrast to 1.2 when only the -O2 optimisation level is
> active and 6.76 without any optimisation.  [...]

> Could someone please fix the inlining problem. [...]

This is a known issue that is being addressed.  The upshot is that
when the default setting of the max-inline-insns parameter was cranked
*way* down to solve compilation time regressions, many large functions
which were explicitly marked to be inlined and that used to be inlined
are no longer being inlined.  Of course, this causes (as you have
found) large run-time speed regressions.

g++ 2.95.X (and before) uses a RTL-based inliner whereas g++ 3.0 uses
a tree-based inliner with a completely different base algorithm.  One
particular change with the new algorithm is that explicitly marked
inline functions are no longer guaranteed to be inlined as was the
nominal case with the RTL inliner.  A key parameter, max-inline-insns,
controls how much inlining may occur based on total size of code to be
inlined into a function in place of a function call.

3.0 used --param max-inline-insns=10000
mainline used 100 until recently when it was cranked back up to 600.
3.0.1 branch currently has 100.

Until a more radical change is made, you can always compile your code
with, e.g., ``g++ -O2 --param max-inline-insns=10000'' to get the old
behavior at the expense of compile-time.

Regards,
Loren