This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[Patch] C++ inlining heuristics changed (3.0.1)
- To: gcc at gcc dot gnu dot org
- Subject: [Patch] C++ inlining heuristics changed (3.0.1)
- From: Kurt Garloff <kurt at garloff dot de>
- Date: Wed, 22 Aug 2001 14:18:29 +0200
- Cc: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Organization: TU/e(NL), SuSE(DE)
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