[Patch] C++ inlining heuristics changed (3.0.1)

[Kurt Garloff]

Hi Richard,

thanks for your report!

On Thu, Aug 23, 2001 at 03:38:22PM +0200, Richard B. Kreckel wrote:
> On Wed, 22 Aug 2001 21:42:29 +0200, Kurt Garloff wrote:
> > I'd like to have this patch included in 3.0.2. (Unless somebody can come
> > with an inliner for 3.0.2 that does not cut inlining at leaves but at the
> > trunk of the call tree.)
> 
> I just bootstrapped successfully with Kurt's patch applied and tested it
> on the benchmarks in GiNaC's suite of regression tests.  Run-time
> performance was somewhere between inline-limit 3000 and 4000 as seen
> before, i.e. close to maximum, so this looks good.  File-size was actually
> slightly smaller than any I have seen before.  (But as to compile-time it
> seems that we are not very sensitive, they varied only about 10%.)

Compared to 3.0.1? It should more or less be the same, yes.
If I want to summarize the patch: It should give 3.0 performance (or better
in case of i-cache effects) at 3.0.1 compile speed (or slightly better :-)

But after 2.95.3 experience, I might come up with a slightly better variant.
http://gcc.gnu.org/ml/gcc/2001-08/msg01110.html
At this moment, C++ inlining is a bit detuned WRT C inlining, I believe; we
need something like 500 or 600 to get good C++ performance, as we only allow
half of this size for single functions. For plain C, this limit might be a
little high; that's unchanged from 3.0.1 though, so no pessimization.

But, I'll check whether I can do the following:
* Set the default max size for inlining to a lower value (300), and use
  it as max size for single functions. (So this stays effectively unchanged
  from v2 of the patch; but the RTL inliner may be more happy, as it uses
  the same number AFAICS so C programmers might appreciate this. OTOH, they
  did not complain too much about 3.0 or 3.0.1, where it was 10k resp. 600,
  did they?)
* Start throttling recursive inlining later (e.g. 4 times the new limit, IOW
  2 times the v2 one)
* Maybe we can somehow also give leaf functions a bonus in the tree inliner
* Maybe we can find a way to compute the minimum limit I fixed to 130
  in v2 of the patch. It should be a function of argument list length etc.
  Don't know, whether it's worth the trouble.

Is the RTL inlining pass (integrate.c) still used, when we compile
C++ with 3.0.1, or is the tree inliner (optimize.c) all that's being 
applied, BTW?

> So, from my limited persective, I would like to recommend Kurt's patch for
> GCC-3.0.2 unless somebody really fixes the inliner for good.

Thx for testing and supporting!
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7hRcjxmLh6hyYd04RAqGmAKCYRNtpgSV68fZqW/j/08QfgYQ9egCeOr7l
57Uptxt5PpmPC+Nc5N6JD+8=
=SCl8
-----END PGP SIGNATURE-----