[Patch] inlining tweaking for 2.95.3

[Kurt Garloff]

Hi,

encouraged by the success of tweaking the 3.0.1 tree inliner (C++),
http://gcc.gnu.org/ml/gcc/2001-08/msg01087.html
I had a look at 2.95.3. We only have the normal RTL inliner here in
integrate.

As the idea that we want to give a preference to leaves seems to be a good
one, I give them a preference by a factor of two (max_insns).
This way, the normal threshold can be set a bit lower, resulting in reduced
memory consumption and lowering the chance of consuming ridiculous amounts
of memeory becaus eof exessive inlining.

Then, I was playing with the number and found an astonishingly low number
needed to yielding maximum performance. Compile time is almost halved for my
tests.

Here are the benchmark results; this time I additionally benchmarked the
tests with std::complex<double> type.
All tests on iPIII-700 (Coppermine) under Linux 2.4.7
                    
max-insn  compile    stripped sizes (B)         TBCI bench specs
          time (u)  double    cplx  std::c    double    cplx  std::c
 100:         1:40   76868  100532   82756     0.919   0.816   0.698
 130:         1:46   80644  102724   85148     0.921   0.847   0.698
 150:         1:47   82484  102620   86460     0.916   0.855   0.782
 180:         1:58   82300  102220  100372     0.918   0.839   0.779
 200:         1:53   82332  104252  100644     0.923   0.846   0.779
 240:         2:08   82364  111268  102588     0.922   0.848   0.781
 240 -O3:     2:11   84660  111364  102436     0.904   0.849   0.776
 300:         2:06   84572  114316  102660     0.921   0.844   0.781
 400:         2:45   88364  114220  104828     0.920   0.846   0.783
 500:         2:44   88364  114180  109644     0.922   0.851   0.780
 600:         3:28   88364  122004  109636     0.917   0.847   0.780

For reference:

2.95.3:       3:37   88364  123636  109636     0.922   0.784   0.780
3.0.0:        3:48   89488  109872             0.873   0.800
3.0.1:        2:50   95620                     0.320
3.0.1/wp:     2:49   83772   98108   93396     0.869   0.845   0.937



>From those numbers, I'd go for 200. In the patch (attached), I chose for 240
to be a bit more safe against risking regression from 2.95.3. The optimum is
probably dependent on the platform, and as we're coming from 10000
(ridiculous value, BTW), I chose a value slightly above the one found
optimal during my tests.

If you compare the max-insns number to 3.0.1 with my patch, note that you
should multiply the 2.95.3 numbers by 2 to have a similar effect.

What do we learn?
* 2.95.3 performs amazingly well with the patch.
* I came up with a simple approach to make 3.0.1 inlining heuristics perform
  much better. Maybe we can even go back to more simplisitc code:
  Just pick a rather low value (300) and make sure we give a bonus to the
  leaves, as we do in 2.95.3 with my patch.
  Additionally, I'd keep the throttling to prevent infinite recusrion when
  inlining. But just start to use it much much later than with plain 3.0.1
  (Before my patch, the limit for a single functions was the same as the
  recursive limit, which yielded very poor results.)
* The INTEGRATE_THRESHOLD seems to work well on 2.95.3; maybe we could
  compute the min_insns in the tree inliner of 3.0.1 with a similar formula.

I would be delighted to get feddback on this patch.
I'd e.g. expect code which uses a lot of inlining (as most C++ code does) to
compile significantly faster. I'd expect KDE to compile in half of the time
e.g. and half a bit smaller executbales. 
Is anybody able to find runtime performance pessimizations?

And, yeah, I would appreciate to find this patch back in 2.95.4. 
Will there be one?

Regards,
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7hNxExmLh6hyYd04RAlKtAJsFvyZ/PfSv5a67QnKIQ2yqEezeTACeNUp3
R+Ae1SMtKuwA15teXzgjEWc=
=S810
-----END PGP SIGNATURE-----