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

[Kurt Garloff]

On Wed, Aug 22, 2001 at 04:26:18PM +0200, Kurt Garloff wrote:
>  ^ (Max size of inlineable fn)
>  |
>  |----------------.                             <-- (b)
>  |                 .
>  |                  .
>  |                   .  slope =: (d)
>  |                    .
>  |                     .
>  |                      .
>  |                       ---------------------  <-- (c)
>  +------------------------------------------------->
>                                     (Size of inlined code:
> 		   ^		     Already inlined + current)
>                  |
> 		  (a)
> 
> This way, we would avoid the theoretical infinite inlining.
> I'll start to play with this a bit.
> I guess, a good starting value for (a) is 600, for (b) 300 and I'd choose
> the slope (d) to be 0.1, i.e. we will reach the inlining limit just before
> 3300 and only inline extremely small functions afterwards.
> 
> Does this make sense?
> Would a patch like this be acceptable for 3.0.2?

OK; I did a lot of benchmarking and
- left (a) at 600
- set (b) to (a)/2 (as before)
- set (c) to 130
- used a slope (d) of -1/16.

Some comments:
* Increasing (a) over 600 only increased compile time significantly
* Decreasing (a) below 500 started to yield worse results
* The optimum of 130 for (c) was found by a lot of compilations:
  Up (and including) to 130 (corresponding to -finline-limit=260), 
  the code size shrinked (!) when increasing this number. So, the
  smallest executables (on ix86) are produced for -finline-limit=260
  and this patch (see numbers below)
* If (b) is smaller than (c), just the (b) limit will apply
* Just to be really sure not to get into trouble (infinite inlining
  with following OOM), I also cut the minimum inline limit (c) after we
  reached 64 * (a).
* (d) has also been experimentally determined.

> Please compare to the numbers reported by myself in
> http://gcc.gnu.org/ml/gcc/2001-08/msg00919.html
>
> inline   compile     size      size       spec      spec
> limit    time(u)   double      cplx     double      cplx
>
>   200     1:38      71764     80365      0.814     0.517
>   400     2:07      82612     89308      0.776     0.562
>   600     2:41      88468    101444      0.870     0.846
>  1000     3:18      87788    103412      0.869     0.844
>  2000     3:49      89148    110732      0.873     0.847
>  5000     3:58      89148    109852      0.872     0.845
> 10000     3:55      89148    109852      0.872     0.846
>
> Just for comparison:
> 2.95.3    3:35      88364    123636      0.912     0.846
> 3.0.0     3:48      89488    109872      0.873     0.800
> 3.0.1     2:50      95620        -       0.320         -
>
> The results look very nice, IMHO.

Here the new results:
 
   200      1:38      71404     81796      0.877     0.519
   260      1:38      68636     73276      0.877     0.610
   300      1:55      77212     81460      0.877     0.651
   400      2:07      79108     82492      0.805     0.637
   500      2:28      84228     97924      0.870     0.839
   600      2:49      83772     98108      0.869     0.845
  1000      3:24      87348    104156      0.869     0.844
  2000      3:37      89148    109924      0.872     0.845
  
Those results look even better: Executables are slightly smaller and run at
slightly higher speed than with the first patch and much better than plain
3.0.1.

I'd like to have this patch included in 3.0.2. (Unless somebody can come
with an inliner for 3.0.2 that does not cut inlining at leaves but at the
trunk of the call tree.)

Complete patch (against 3.0.1) attached.

The copyright for this little contribution is herewith assigned to the FSF.
I did bootstrap the compiler on two machines (both ix86). If more
architectures are required, please tell me; I could check on some SuSE
machines ... 
OTOH, I have difficulties to imagine how this patch could break
bootstrapping, first because it's trivial code and second because it's 
C++ only.
make info and make dvi both succeeded.

Running the testuite on gum07:
garloff@gum07:/usr/src/gcc-2.96/i686-pc-linux-gnu $ make check    
[...]
WARNING: Couldn't find tool init file
Test Run By garloff on Wed Aug 22 21:32:07 2001
Native configuration is i686-pc-linux-gnu

                === libstdc++-v3 tests ===
		
Schedule of variations:
    unix
    
    Running target unix
    Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/gcc-2.96/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /usr/src/gcc-2.96/libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp ...
ERROR: tcl error sourcing
/usr/src/gcc-2.96/libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp.
ERROR: couldn't compile regular expression pattern: quantifier operand invalid
    while executing
"regsub "^$srcdir/?" $prog "" name"
    (procedure "dg-test" line 37)
    invoked from within
"dg-test $testcase $flags ${default-extra-flags}"
[...]

Hmmm, is this box too old?
		

Please apply!

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

iD8DBQE7hAskxmLh6hyYd04RAktOAJ9MIwlPqra72+q28tgdwQIahUWdAQCcCA9f
VXMvhSNOziPjOX1PB0oGGbQ=
=IUi9
-----END PGP SIGNATURE-----