This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining and estimate_num_insns
On Sunday 27 February 2005 10:57, Richard Guenther wrote:
> 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.
>
> How do you suppose we fix the three-fold run-time performance
> regressions I and other people see for their scientific code?
I'm not sure, but 1) I have large C++ codes and don't see such
slowdowns, and 2) I see no reason to kill compile time for everyone
just to work around the (ahem) lameness of heavily templatized code
in a relatively small number of C++ applications. I understand it
is a problem for a few people, but if you look at the performance
numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
to be any performance problem. But your patch will probably still
blow compile time through the roof for those applications as well.
Gr.
Steven