Re: cgraph based inlining heuristics

[Jan Hubicka <jh at suse dot cz>]

> On Wed, 2 Jul 2003, Jan Hubicka wrote:
> 
> > > Hi,
> > >
> > > thanks for your continued work on improving gcc3.4 inlining!
> > >
> > > Did you check any of the POOMA testcases with the new heuristics yet?
> > > I realize these could be only compile-time tests, but I'd be interested
> > > especially in the tramp3d numbers.
> >
> > I am really curious about your results!
> 
> Ok, here they go. I tested four different setups:
> 
> (0) gcc3.4
> (1) gcc3.4 with __attribute__((leafify)) patch
> (2) gcc3.4 with your patch
> (3) gcc3.4 with your patch and -funit-at-a-time
> (4) gcc3.4 with your patch and -funit-at-a-time --param max-inline-insns-auto=200 --param max-inline-insns-single=200 --param inline-unit-growth=1000 --param large-function-growth=1000
> 
> flags otherwise used are
> -O2 -g -march=athlon -fno-math-errno -fno-trapping-math -ffinite-math-only
> -funroll-loops
> 
>                       (0)         (1)        (2)       (3)       (4)
> binary size        10166017    10681144    8405237   8405237   9874056
> compile time      2m57.503s   3m40.638s  1m19.553s 1m20.742s 2m55.031s
> runtime performance   3.97s       1.66s      2.65s     2.64s     1.74s
> 
> timings are seconds per iteration. The new heuristics are a huge
> improvement, both in compile and runtime! I suspect from the numbers,
> that -funit-at-a-time is enabled at -O2 already? Also we probably get

I do it in my tree, so I more likely hit the bugs during bootstraps, but
it is not the case in the mainline.  I would like to see it enabled at
-O2 in the future assuming that it makes average compilation faster.

You may also try -fno-unit-at-a-time flag.  They you will get old
heuristics with new code size estimates, so you can see how much of
benefits comes from each.

My numbers were with -O3, you may want to try these too :)

> the performance of __attribute__((leafify)) with no extra compile time
> or binary size increase compared to (2) and (3).
> 
> So in conclusion - MANY thanks for your work! I hope it gets accepted
> soon. Also I still think __attribute__((leafify)) is a useful hint to
> the compiler to optimize without paying for it at other places (tuning
> params as in (4) hurts too much and is not very easy to tune).

Thanks :)
I think I can try out the leafify idea, but probably after the
"vacation" I am leaving to at friday.

Honza
> 
> Thanks,
> 
> Richard.
> 
> ---
> Richard Guenther <richard dot guenther at uni-tuebingen dot de>
> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/