This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tree-ssa status (was: Re: Dropping of old loop optimizer)
Op do 27-02-2003, om 20:46 schreef Diego Novillo:
> On Thu, 27 Feb 2003, Steven Bosscher wrote:
>
> > There is a difference between things that "work fine" and things that
> > "are ready".
> >
> Yup.
>
> > What, for example, is the compile time performance on the branch? SPEC
> > results compared to mainline? If I correctly interpret Diego's SPEC
> > tester results, it does not quite look like it's there yet.
> >
> Yes, we are not quite there yet.
>
> Since you brought it up, I got curious and gathered a few stats.
> This is how the branch looks today in terms of compile time
> compared with mainline:
>
> - All times are in seconds.
> - All the compilers are built with ENABLE_CHECKING.
> - Bootstrap times are for all default languages (C, C++, Java,
> Fortran and ObjC).
>
> ------------------------------------------------------------------------
> Build times mainline tree-ssa Difference
> ------------------------------------------------------------------------
> SPEC95 375 418 +11%
> SPEC2000 517 586 +13%
> Bootstrap 3247 3588 +10%
> ------------------------------------------------------------------------
Mwah, that is not as bad as I thought. And comparing the branch to the
mainline just like that is not really fair IMO (which is why I didn't do
it), because eventually there should be optimizations we do on RTL that
have virtually no effect while they may ruin compile time. If you take
that into account it really doesn't look that bad.
It would be interesting to know the total time spent in the RTL
optimizers for mainline and branch...
> In terms of runtime performance, the branch is ~3% slower on
> SPECint2000 and ~11% slower on SPECfp2000. There's a couple of
> individual tests where the branch is marginally faster than
> mainline. The branch also fails to compile vpr, eon and perlbmk.
Ooof ouch, 11%!
The worst slowdown is obviously in 179.art. What's so special about it
that makes the branch twice as slow?
> - Investigate what can be modified/removed/simplified in the RTL
> backend due to the different "flavour" of RTL that the tree
> optimizers emit. I suspect that we could get a big compile
> time boost if we could get rid of unnecessary work in the
> backend. We could also find that we need some more additional
> passes at the tree level that we still haven't thought of.
Define "unnecessary"...
Ideally we'd have all front ends use the tree infrastructure. That
would allow us to blow away big chunks of RTL optimizers, and indeed one
would expect to see a potentially significant win in compile time from
that.
But it seems that we'll be stuck with at least one front end that will
probably never be able to do function-at-a-time compilation (g77). It
was said here once that Ada will do function-at-a-time??
> So, it's a lot of work. Will it be ready for 3.5's stage1? I
> don't know. Particularly if the list of requirements grows
> bigger. The integration work will also be interesting. I diff'd
> mainline and the branch a few days ago:
>
> 307 files changed, 80994 insertions(+), 4342 deletions(-)
How much of those insertions are in new files?
> > (I can send you a patch to update the web page iyl. It still claims
> > you're using FUD chains :-)
> >
> Oops. Patches appreciated!
I'll make one.
Greetz
Steven