[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    How to choose reasonable default inlining limits?
From:       Richard Guenther <rguenth () tat ! physik ! uni-tuebingen ! de>
Date:       2005-02-27 13:53:47
Message-ID: 4221D0EB.9070706 () tat ! physik ! uni-tuebingen ! de
[Download RAW message or body]

Hi!

As you may have noticed I'm at changing estimate_num_insns and getting
compile time regressions this way.  Of course.  How do/did we choose
the current default inlining limits in the params.def file?  While code
size estimates from 3.4 to 4.0 changed quite drastically, only one
of the inlining limits defaults were changed from 3.4 to 4.0, namely
max-inline-insns-auto (from 100 to 120).

I added up the function size estimates for (common) functions compiling
mainline with 3.4, 4.0 and 4.0 with the patch at
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html

The results are quite confusing considering we didn't change the 
inlining limits:
                 insns
   3.4           989098    +0%
   4.0          1144765   +16%
   4.0 patched   883858   -11%

which either suggests we do not care about such small variations or we
are happily enjoying the compile time benefit of inlining less functions
on mainline.

There are a few confusing points with the current limits anyway:
   1. max-inline-insns-auto is very much lower (120) than
      max-inline-insns-single (500), while max-inline-insns-recursive
      is the same as max-inline-insns-recursive-auto (500)
   2. 500 is very high for max-inline-insns-single considering that
      out of all functions in gcc 85% are smaller than this (with the
      3.4 estimate).  So, effectively we are not limiting inlining of
      functions marked with "inline" with this limit, but rather with
      the unit/function growth.  Instead our real limit is
      max-inline-insns-auto with -finline-functions, which is high, too
      (36% of all functions in gcc are smaller than 100 with the 3.4
      counting, 39% smaller than 120 with the 4.0 counting, this includes
      functions like cp/pt.c:get_class_bindings).
   3. we have a large-function growth limit that kicks in only for large
      functions, but our unit-growth limit kicks in at any starting size.

How did we get to the above limits anyway?

Does anyone have testcases where we can easily see that we have/have not
inlined the right stuff?  If I take f.i. the MICO package and compile it
with 4.0 I get a compile time increase of 3.5% with the patch applied,
but I have no ways to test if this has a positive effect elsewhere.

Richard.
[prev in list] [next in list] [prev in thread] [next in thread]