Inliner parameters

[Steven Bosscher]

Op wo 16-04-2003, om 23:17 schreef 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.

Yes, but the stuff you're inline throws everywhere, from recursively
inlined functions.  So if you do EH, you're inlining lots of throws. 
Remember that 3.2 could do EH _and_ inlining about 12 times as fast as
3.3 for your test case.  Has EH slowed down so much from 3.2 to 3.3 that
it would explain a 1200% compiler slowdown (and even worse before Mark's
fixup_thingy O(t^2) fix that is not even on the 3.2 branch)?  I sure
hope not.


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

What happened to the compile times with bigger min-inline-insns?

Have you also tried different values of max-inline-slope?  Larger values
of that param should also increase the number of inlined functions.

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

It has been suggested before that C and C++ require different inline
parameters.  INSN counting seems a bit crude, with INSNS_PER_STMT. 
Maybe we should play with that a bit, see if the default value of 10
makes sense for C++...  What is that number based on anyway?  Maybe the
number of INSNs could be varied per tree code.  Surely, on the tree-ssa
branch with GIMPLE it should be possible to make a better estimate of
the number of insn per statement?

> And we should certainly get -funit-at-a-time
> working for C++ in mainline.

That would be really cool, yes.

Greetz
Steven