Re: Inliner parameters

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On 17 Apr 2003, Steven Bosscher wrote:

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

The following tests are for g++-3.3 (GCC) 3.3 20030414 (prerelease)

Compiling my worst-case example with -O2 -fno-exceptions --param
min-inline-insns=X gives

   X     compile-time
  50       11.25   [uses 112MB ram max]
 100       11.25   [112MB]
 150       11.50   [112MB]
 200       11.50   [113MB]
 250       12.50   [110MB]
 300       12.75   [110MB]

g++-3.2 (GCC) 3.2.3 20030414 (prerelease): 9.50   [73MB]

and with -O2 --param min-inline-insns=X (EH turned on)

   X     compile-time
  50      178.75   [uses 359MB ram max!]
 100      178.00   [368MB]
 150      179.75   [363MB]
 200      180.25   [363MB]
 250      killed after 4min [559MB - we're swapping us to death..., seems
          we're starting to inline EH stuff here]
 300      wouldn't be any better, I suppose

g++-3.2 (GCC) 3.2.3 20030414 (prerelease): 11.00  [81MB]

note the difference in with/without EH, especially the memory requirements
(the machine has 512MB of ram).

So I really think we have a problem with EH left...

And I assume we can safely raise min-inline-insns at least for C++ code.

I'll post numbers of my performance test as a follow up (this one needs
the min-inline-insns bumped and so may show different compile time
characteristics).

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

Yes, but apart from setting it to gazillion, the required value (to make
good performing programs) depend on the actual code that is compiled. F.I.
I usually get empty destructors not inlined and such simple stuff if just
the nesting level is deep enough. This doesnt happen with adjusting
min-inline-insns.

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

Also do we account for constant parameters passed to to be inlined
functions? If not we're over-estimating the number of resulting
instructions for such calls.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/