GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

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