Inliner parameters

[Richard Guenther]

> Hi,
>
> Many 3.3 compile time regressions from 3.2 seem to be caused by the new
> tree inliner heuristics.  There are at least a few PRs for which the

They may be related to EH reorganization as well, as noted, f.i. in
PR 10196.

> inliner apparently causes serious compile time regressions (PRs 10160,
> 10196, and 10316 and part of 8361 as well).  Obviously those PRs are
> just the tip of the proverbial iceberg...
>
> All these compile time regressions disappear when the inlining limit is
> changed.  It looks like the 3.3 inliner is a much more agressive, but I
> have not seen any data to confirm this.
>
> When was the last time somebody tried to tune the parameters a bit?  Did
> anyone try the effects of different parameter settings for, say, SPEC
> and POOMA (and, ideally, on more than one platform)?

I tried various parameters for POOMA to tune the performance of the
optimized code and the key parameter to change was min-inline-insns.
This is _way_ too low for POOMA to collapse the expression template
trees. I need to bump this up to 250 to get good performance. The
max-inline-insns-single can be dropped to 250 without loss then.

Maybe the insn counting for small C++ template methods is just way off
compared to C programs? Maybe we should have different default parameters
for C and C++ programs? And we should certainly get -funit-at-a-time
working for C++ in mainline.

Richard.