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

[Kurt Garloff]

Hi,

thanks for confiming my suspicion, Daniel, that the leaves of the inlining
tree will get cut off inlining instead of the root by the C++ tree recursive
inlining limit. How stupid! The least you want is to not inline the
iterators at the end of your call chain!

Here's a band-aid: 
Use 3 limits:
(a) The limit given by max-insns
(b) Half of it for single-fn inlining
(c) A quarter of it for recursive stuff above limit

Now, here's what g++ does after applying the patch:
* Single functions larger than (b) do not get inlined
* Once we exceed (a) through recursive inlining, only
  single functions smaller the (c) will get inlined.
  
This will prevent cutting the small functions at the end (the leaves) from
being inlined if they are small enough.
Patch against 3.0.1 for cp/optimize.c attached.

Things for discussion:
* One could think of aggravating the limit (c) when we're far beyond (a) on
  recursive inlining.
* The exact numbers (a), (b), (c) are open for discussion.  
* The reason why I want (b) smaller than (a) is that I want to improve the
  chance to cut early. (First tests indicate that this could be changed to
  3/4 or just left out with not much effect on runtime performance.)
* Who will implement inlining that does cut the trunk instead of the leaves?
  (which is the real solution IMHO)

It works amazingly well on my test program: With -finline-limit=600 I get
more than 90% of the peak performance.

Compile time and result statistics to follow in a subsequent mail.

Gerald, could you test as well?

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

iD8DBQE7g6MUxmLh6hyYd04RAi/aAJ9u3goZqNjpe368ZLwFwfft5Ie3aQCdFZAD
QqdKPhfESzwz+zFqIjZjaPE=
=quSo
-----END PGP SIGNATURE-----