Re: Inlining and estimate_num_insns

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sun, 27 Feb 2005 02:04:19 +0100, Richard Guenther
<rguenth@tat.physik.uni-tuebingen.de> wrote:
> Steven Bosscher wrote:
> > On Saturday 26 February 2005 23:03, Jan Hubicka wrote:
> >
> >>Mark?  I would say that there is little risk in this patch corectness
> >>wise, might have negative effect on compilation times since we re-start
> >>inlining more like we did in old days.
> >
> >
> > Can we see some timings with and without this patch?
> 
> tramp3d-v3 -O3 compile- and run-times without checking are
> 
>                 compile     size      run
>   3.4           1m7s        4421288     51s
>   4.0           1m2s        4531197   1m57s
>   4.0 patched   2m39s       5391554     27s
>   3.4 leafify   1m36s       4539503     34s
>   4.0 leafify   1m52s       4844784     15s

Further testing shows that the tramp3d testcase benefits most by the
removed abstraction penalty.  With --param max-inline-insns-auto=80
--param max-inline-insns-single=80 we get

  4.0                0m55s     4663068   45s
  4.0 patched  1m32s     5069229   26s

uh oh?  I don't understand the unpatched number - that looks like we
do not "sort" our inlining decisions to first.  500 as default for
max-inline-insns-single
looks very large anyway.

--param max-inline-insns-auto=50 --param max-inline-insns-single=50
 4.0                 0m49s     4749444   1m2s
 4.0 patched   0m58s     4952254       40s