This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)
--- gcc/cp/optimize.c.orig	Thu Jun  7 00:50:22 2001
+++ gcc/cp/optimize.c	Wed Aug 22 14:01:16 2001
@@ -641,7 +641,7 @@
   else if (varargs_function_p (fn))
     ;
   /* We can't inline functions that are too big.  */
-  else if (DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS)
+  else if (DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS / 2)
     ;
   /* All is well.  We can inline this function.  Traditionally, GCC
      has refused to inline functions using alloca, or functions whose
@@ -657,7 +657,8 @@
      be that we've done so much inlining already that we don't want to
      risk inlining any more.  */
   if ((DECL_NUM_STMTS (fn) + id->inlined_stmts) * INSNS_PER_STMT 
-      > MAX_INLINE_INSNS)
+      > MAX_INLINE_INSNS
+      && DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS / 4)
     inlinable = 0;
 
   /* We can inline a template instantiation only if it's fully

PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]