Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher <stevenb at suse dot de>]

On Monday 30 August 2004 02:53, Mark Mitchell wrote:
> >Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
> >just about every project using GCC complaining about how GCC gets slower
> >with each release?
>
> Obviously, this is not ideal.  However, we have few practical
> alternatives.  I am not convinced that any further delay will get us
> better results.  I do not see a broad committment to improving
> compile-time speed when optimizing: in fact, I got zero proposals from
> people planning to work specifically on that issue.

It is funny that you say here that you got zero proposals, yet you
had a section in your mail:
> -------------------------
> Compile-Time Improvements
> -------------------------
> 
> There were three submissions relating primarily to compile-time

Also, I believe the edge-vector-branch work is also purely a speedup
project - it will make looking up PHI arguments much faster.  As I
have shown before on this mailing list, this is one of the major bottle
necks for passes like DOM.

Merging the LNO ivopts is another pass that could help win back speed
because it would allow us to kill the old loop optimizer (ie. loop.c 
and unroll.c) and all the yuckie-ness that it causes, like
reconstructing the CFG, recomputing dominance, recomputing loop info,
etc. etc.  All of that is expensive, and removing expensive things is
a good thing...

Anyway, you are probably right that there appear to be few people
working *specifically* on speeding up the compiler.  But many people
work on replacing expensive RTL optimizations with cheaper tree ones.


> Maintaining compilation speed was a precondition set by the SC for the
> tree-ssa merge.  If that condition was not met, then perhaps the merge
> should not have been performed.  The fact that it was probably indicates
> that people weren't too worried about these compile-time effects.

We discussed compile time back then and it was believed that we could
win back enough speed before stage3 to get back to around GCC 3.4 speeds,
which is IMO a good start.  After that, the Summit happened and suddenly
everyone was working on re-doing much of tree-ssa.  We're also slower
now than we were at the merge point.
So yes, in retrospect perhaps the merge did come too early.


> I continue to think it will take at least another several months to
> really get to the point where tree-ssa is unambiguously better
> (consistently better code, consistently better compile-times, fewer
> bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June,
> and SC approves, it's OK with me.

If we can restrict ourselves to the features proposed in your list,
and work on just getting those items ready, releasing GCC 3.5 later
would IMHO be much better than rushing it out in January.

Gr.
Steven