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

[Kurt Garloff]

Hi Gerald,

thanks for giving it a try!

I'm of course also interested in the results with v2 of the patch.

And you may also give my 2.95.3-patch a try if you like.

Note, that I recommend against using -finline-functions (aka -O3), as it
decreases performance for well written code, i.e. code that has all the
inline where it makes sense.
Well, I'll also play with that a bit, just throttling the -O3 case a bit
earlier than currently.

For 2.95.3, changing
define INTEGRATE_THRESHOLD(DECL) \
  (optimize_size \
     ? (2 + (1 + 3 * list_length (DECL_ARGUMENTS (DECL))) / 2) \
     : (8 * (8 + list_length (DECL_ARGUMENTS (DECL)))))
into         ^
define INTEGRATE_THRESHOLD(DECL) \
  (optimize_size \
     ? (2 + (1 + 3 * list_length (DECL_ARGUMENTS (DECL))) / 2) \
     : (8 * (7 + list_length (DECL_ARGUMENTS (DECL)))))
             ^
seems to be enough to not see any adversary effect any more using -O3 
for one the little test case I tested so far. More to follow on this front.

Without -finline-functions you should see better compile times with 3.0.1 +
my patch than with 2.95.3 plain. (2.95.3 plus patch is faster).

On Thu, Aug 23, 2001 at 02:32:32PM +0200, Gerald Pfeifer wrote:
> On Wed, 22 Aug 2001, Kurt Garloff wrote:
> > Gerald, could you test as well?
> 
> Done. And, I'm extremely positively surprised and impressed. First the
> build benchmarks, then run-time benchmarks:
> 
>   -O3		GCC 2.95.3  GCC 3.0   GCC 3.0.1	3.0.1+patch
> 
>   Compile-time	6:00	    32:15     7:46      6:41
>   Binary size	4377664     6213988   4160356   3948196
> 
> Summary: With your patch, my binaries are smaller than ever before, and
> compile-time is below 3.0.1 and even approaching the one with 2.95.3
[...]
> Summary: Still worse than 2.95.3 in most cases, but significantly better
> than 3.0.1 (which in turn is quite a bit worse when compared to 3.0).

Now, I did expect an improvement for your testcases, but not such a huge
one; the fact that 3.0.1+patch beats 3.0.1 at runtime is expected, for
compile time, I did not really expect it.
What does actually surprise me, is that 3.0.1 + patch does beat 3.0 in
almost all of your benchmarks. 
It seems, 3.0 just did much too heavy inlining, apparently so much, that you
spoil your CPU's instruction cache. 

> I *strongly* opt for adding Kurt's first patch which is incredibly simple
> to both branches as soon as possible (and then wait for his copyright
> assignment etc. before we can consider his more complicated patches).

Thanks for your support! 
Seems I have to undergo this annoying procedure now ...
(I do believe that the patch is trivial -- but once you found something it's
 always obvious. That's why I still can't believe that somebody who has about
 zero knowledge of the compiler's internals (i.e. me) could successfully solve
 this problem, which bothered me for quite a while, now.)

> Okay to install his patch on both branches?

Well, for 2.95.3, I have a different one ;-) as we don't have the tree
inliner there obviously. But you refer to 3.0.1 and 3.1-CVS, I guess?

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

iD8DBQE7hQZhxmLh6hyYd04RAqPNAJ9vSoxUAli/fc+cq2JhAJ2C5G7nrwCfZTVx
BmQutnmUhVOrSQhAqq4mQjA=
=T6em
-----END PGP SIGNATURE-----