This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining and estimate_num_insns
> Steven Bosscher wrote:
> >On Feb 27, 2005 02:04 AM, Richard Guenther
> ><rguenth@tat.physik.uni-tuebingen.de> wrote:
> >
> >>In the end we surely want to watch CiSBE and SPEC testers.
> >
> >
> >Maybe so, but your timings already show this is pretty unacceptable.
>
> Well, the compile time regressions are not caused by my patch but only
> exposed by them. Previously we were saying "hey, we are as fast as
> 3.4", but really comparing apples and oranges, as we regress badly in
> performance by just doing less work due to less inlining. If you want
> to throttle that back, you can as well, as a followup patch, reduce
> inlining limits. That of course doesn't remove the conceptual
> improvement of estimating the size of an inlined indirection the same
> as the actual function.
Agreed here (this is mostly one of reasons why I hoped I won't need to
touch 4.0 inlining limits too much since I was affraid of the slowdowns,
yours benchmarks are however pretty convincing especially that there are
obviously more than single application hitting this) , but I am really
unsure we want to see the slowdown.
Can you, please, try to experiment a bit about how low you can go with
the tests to not ruin the performkance.
I will do some additional testing on Gerald's application and SPEC
testers hopefully tonight - I am recovering from yesterday disk crash
and day before yesterday exam... uhm.
Honza
>
> How do you suppose we fix the three-fold run-time performance
> regressions I and other people see for their scientific code?
>
> Richard.