[Patch] inlining tweaking for 2.95.3

[Kurt Garloff]

On Thu, Aug 23, 2001 at 12:34:44PM +0200, Kurt Garloff wrote:
> 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.

Unfotunately, benchmarking many more apps, I found runtime performance
between 20% worse to 5% better; now I think we want to avoid the 20% worse
within the 2.95 tree. (Well, the 3.0.1 did yield degradations of more than a
factor 2 as compared to 3.0, but that's another story.)

The patch should be included, but we may want to discuss the exact default
value for the inline-limit:
* With 400, I still get considerably better compile time with slightly
  smaller binaries; runtime performance varies between 5% worse to 5% 
  better. (Avg. seems to be slightly worse, like 1%.)
* With 1000, we would almost restore the 2.95.3 behaviour, except for 
  crazily huge inline functions. Now, we want to avoid them anyway,
  in order to improve runtime performance and in order to not consume
  excessive resources.
  (I do consider this a bug fix; I got a little C++ test program that will
  make G++-2.95.3 consume > 0.5GB memory with optimization. Without, it
  gets compiled in a few seconds with only tenths of MBs memory consumption.)

Note that code that does not do heavy inlining, such as most C code, is not
affected at all by the patch, unless you do -finline-functions aka -O3.

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

Now, I was too optimistic here, I guess. But something like 15% improvement
still seems reasonable to me.

> Is anybody able to find runtime performance pessimizations?

I'd like to get reports, especially with the second version of the patch.
If you find pessimization, what is the effect of changing X in
-finline-limit-X to e.g. 200, 260, 320, 500, 750, 1000, 2000?

New patch (defaulting to 400) attached.

> And, yeah, I would appreciate to find this patch back in 2.95.4. 

This one should be ready for inclusion, I believe.

> Will there be one?

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

iD8DBQE7hie7xmLh6hyYd04RAgNEAJ9LDgpUuRE/eP9d0sYteTBLCaUJuQCgxtjz
2vHJmiY40Em/2pR3Ikr58UI=
=t+rX
-----END PGP SIGNATURE-----