Re: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)

[Kurt Garloff <garloff at suse dot de>]

Hi,

On Tue, Mar 04, 2003 at 02:27:45AM +0100, Kurt Garloff wrote:
> On Sun, Mar 02, 2003 at 12:07:01PM -0800, Geoff Keating wrote:
> > This looks OK to me, but it doesn't apply cleanly to HEAD.  I'll
> > update it, run a bootstrap, and apply it there.
> 
> Fine, thanks! 
> (If you prefer I can do the rediff against HEAD myself, just let me know.)

Just saw that it has already been applied to HEAD. Thanks!

So, two things to do remain:

1. In gcc-3_3-branch, the first patch (as attached in the mail from
   saturday) should IMHO be applied as it fixes PR/8387. Before 3.3.0
   release if it's further delayed, otherwise afterwards.
   Note that we've seen a kernel compile failure on x86-64 with 3.3
   snapshots which was due to a a function not being inlined because
   it was considered too large and the increased -finline-limit passed by 
   the Makefile was not effective.
   So if kernel compilation is a release criterium for 3.3, the fix 
   should go in in any case.

2. In HEAD, we now have the infrastructure to differentiate between
  compiler-flag-inlined and inline-declared functions when taking 
  inlining decisions, but the default limit for both cases is identical
  right now. In real life, this should probably be changed, as people
  that tune their compiler options to get optimal code will probably 
  play with -finline-limit, but rarely with --param max-inline-insns-auto. 
  To determine the right ratio between max-inline-insns-single and
  max-inline-insns-auto, we should play with lower --param
  max-inline-insns-auto values and see how compile and runtime
  performance with -O3 compilation changes.

  My experience is that we should set it to a lower value than
  max-inline-insns-single. In my local build, I used val*2/5 instead
  of val/2 for that one (val is the -finline-limit arg), giving defaults 
  of 600(recursive),300(single),240(auto),130(min). This gives functions
  declared inline an advantage over functions only picked by
  -finline-functions (-O3), so the hint provided by the programmer with
  the keyword is not completely discarded by -O3, assuming that programmers
  that did use the inline keyword (or used in class decl implementations in
  C++) did think about it.
  This allows compiling my numerical benchmarks (TBCI: templated C++ 
  vector and matrix operations) with -O3 without hurting either compile 
  time performance nor runtime performance significantly.

  When testing was done by Andreas Jaeger (in may 2002!), we've seen 
  a few percent regression in the peak (-O3) value in one of the SPEC
  benchmarks, because of the lower limit, though. That's why the default has
  been set back to 300 in the patch (meant to go into 3.3 as well, at that
  time). 
  So, probably, we want to have a lower initialization for the 
  max-inline-insns-auto parameter (val*2/5 or val/3) but use a slightly
  increased default value for -finline-limit, like e.g. 720 with /3,
  resulting in 720,360,240,130. Or 700 with 2/5, giving 700,350,280,130.
  My benchmarks suggest numbers in this region.

  But probably others also want to check what their benchmarks tell.

Regards,
-- 
Kurt Garloff                   <kurt at garloff dot de>             [Koeln, DE]
Physics:Plasma modeling <garloff at plasimo dot phys dot tue dot nl> [TU Eindhoven, NL]
Linux:SCSI, Security           <garloff at suse dot de>    [SuSE Nuernberg, DE]

Attachment: pgp00000.pgp
Description: PGP signature