This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.5 Status (2004-08-29)
Steven Bosscher wrote:
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:
I had zero proposals that described among their benefits compile-time
speed *when optimizing*. Perhaps Elliston's work will indeed help with
that, but it wasn't called out seprately. I'm all for that work on lots
of levels, which is why when we were talking about projects we could
trade for aliasing, I suggested hanging on to that one.
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.
Note that "merge LNO" is still on the plan, and I will be helping with
that where I can. Is the ivopts stuff already there, or is it
different? If it is already there, then perhaps you should work on
getting the old loop optimizer ready to die, so that we can do as you
suggest above. That might be a bigger, and easier to achieve,
compile-time-when-optimizing improvement than Dan's stuff.
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.
It's water under the bridge in any case. But, now, we have to decide
what to do next.
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.
I think it will be very hard to keep people from doing more stuff. The
argument is going to be "my thing is ready, and tested, and seems to
help something, so why can't it go in?" But each of those changes will
introduce follow-on issues.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com