This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inliner parameters
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 16 Apr 2003 23:17:50 +0200 (CEST)
- Subject: Re: Inliner parameters
> 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.