This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Inlining again...
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 7 May 2003 19:39:57 +0200 (CEST)
- Subject: Inlining again...
Hi!
I just wondered today why contrary to --param min-inline-insns=250 still
empty destructors and random other stuff do not get inlined and stumbled
over the following code in tree-inline.c:inlinable_function_p
...
/* In the extreme case that we have exceeded the recursive inlining
limit by a huge factor (128), we just say no. Should not happen
in real life. */
if (sum_insns > MAX_INLINE_INSNS * 128)
inlinable = 0;
else ...
I just placed a warning here, and viola - it triggered 89729 times until
I killed it off. This is of course special for my personal code which is
based on the POOMA library.
Killing the offending check with
Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.38.2.8
diff -u -u -r1.38.2.8 tree-inline.c
--- tree-inline.c 2 May 2003 19:52:01 -0000 1.38.2.8
+++ tree-inline.c 7 May 2003 17:36:26 -0000
@@ -1007,17 +1007,12 @@
{
int sum_insns = (id ? id->inlined_stmts : 0) * INSNS_PER_STMT
+ currfn_insns;
- /* In the extreme case that we have exceeded the recursive inlining
- limit by a huge factor (128), we just say no. Should not happen
- in real life. */
- if (sum_insns > MAX_INLINE_INSNS * 128)
- inlinable = 0;
/* If we did not hit the extreme limit, we use a linear function
with slope -1/MAX_INLINE_SLOPE to exceedingly decrease the
allowable size. We always allow a size of MIN_INLINE_INSNS
though. */
- else if ((sum_insns > MAX_INLINE_INSNS)
- && (currfn_insns > MIN_INLINE_INSNS))
+ if ((sum_insns > MAX_INLINE_INSNS)
+ && (currfn_insns > MIN_INLINE_INSNS))
{
int max_curr = MAX_INLINE_INSNS_SINGLE
- (sum_insns - MAX_INLINE_INSNS) / MAX_INLINE_SLOPE;
increases compile time for my program from about 9 minutes to 20 minutes,
but gets a performance increase in the running code from 185.913s/it to
143.996s/it - a 30% increase in performace.
I think the hunk above, while it protects against unusual long compile
times, goes against the spirit of min-inline-insns parameter and hurts
optimization much.
So I vote to apply the above patch and see, if anyone with "Real World
Code"(TM) complains ;)
Richard.