Re: cgraph based inlining heuristics

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On Wed, 2 Jul 2003, Richard Guenther wrote:

> 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
> the performance of __attribute__((leafify)) with no extra compile time
> or binary size increase compared to (2) and (3).

This is confusing sentence. I meant, if we implement
__attribute__((leafify)) we wont pay a compile time and possibly no binary
size penalty (in my case).

Richard.

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