This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]