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

[Mark Mitchell <mark@codesourcery.com>]

Steven Bosscher wrote:

>On Monday 30 August 2004 02:03, Mark Mitchell wrote:
>  
>
>>Steven Bosscher wrote:
>>    
>>
>>>On Monday 30 August 2004 01:17, Mark Mitchell wrote:
>>>      
>>>
>>>>The following changes will be postponed until GCC 3.6.  These changes
>>>>either provide too little benefit, are too risky, or will take too
>>>>much time to complete.
>>>>
>>>>* Aliasing improvements for structure fields [Berlin]
>>>>        
>>>>
>>>But you should
>>>realize that this analysis is absolutely critical if GCC 3.5 is going
>>>to perform reasonably well.
>>>      
>>>
>>I am not convinced of this statement.
>>
>>First, the compiler speed argument mostly affects optimizing
>>compilations, where compile-times are much less critical than
>>non-optimizing compilations.  I'm sure that people will want to argue
>>this point, but I've been talking with customers for a decade and the
>>ones concerned about compile-times are almost always willing to have
>>optimizing compilation take longer.
>>    
>>
>
>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. 

We have no way of knowing for sure that Dan's work will help here 
either, or how many follow-on effects there will be.  If Dan's work does 
what we expect, then we can turn off some RTL optimizers.  That will 
help, but I doubt it will help by a factor of two.  We've been looking 
at compile-time issues a lot lately, and generally these turn out to be 
pretty subtle.  Since Dan's work requires touching lots of code, it will 
introduce bugs.  They will have to be fixed.  We will likely uncover 
other latent bugs as a result of Dan's code making things more aggressive.

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.

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.  Otherwise, I think we proceed, and 
accept that the release will be useful to some people and less useful to 
others.  (It will, for example, be useful to people who need support for 
new targets, or want gfortran, or want faster non-optimizing compile 
times, which we are now seeing for some C++ programs.)  There are always 
people who declare any given release to be "totally broken".

>>the common cases to achieve most of the benefits.
>>    
>>
>
>What is your confidence based on?  What common cases?  Did Dan tell you
>about the issues that he's fighting?  No "less comprehensive" solution
>exists that will not run into the exact same problems.
>  
>
My confidence is based on the fact that there are generally such 
solutions to most such problems in software engineering.  Perhaps this 
is the very rare case where there is no acceptable short-term solution 
that gets much of the win, but I'd be surprised.

>>Third, if this change is so vital, then we should be willing to drop
>>some other changes in favor of this one, so that people can work with
>>Dan to finish this one.  Why don't you suggest some changes that are
>>already on the list that you'd be willing to give up?
>>    
>>
>
>The things I currently work on that I would drop right away:
>* Edges-in-vectors conversion [Elliston]
>* Tree-based profile-directed feedback [Hubicka]
>
>Things that I think are not as important as beter AA:
>* Linear loop transforms [Berlin]
>* Variable expansion optimization [Eres]
>* Tree-based branch prediction [Hubicka]
>...and probably other stuff, but these are the only ones from which I
>think we reasonably expect that they would help Dan (hey, is he on that
>list?!) with his AA work.
>
That's roughly the same list I would have come up with, with the 
exception of Elliston's changes, which I think are important precisely 
because they will likely reduce memory usage and help compile times.  If 
Dan, Jan, and Revital are willing to abandon their other projects and 
will commit to working with you on aliasing, and together, you think 
that you can get things done much more quickly, let me know.  (There is 
probably not much to be done for linear loop transforms, since Dan 
indicates that it is already submitted.)  I am willing to trade.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com