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] |
On Monday 30 August 2004 02:03, Mark Mitchell wrote: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.
Steven Bosscher wrote:
On Monday 30 August 2004 01:17, Mark Mitchell wrote:I am not convinced of this statement.
But you shouldThe 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]
realize that this analysis is absolutely critical if GCC 3.5 is going
to perform reasonably well.
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?
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.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.
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.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.
-- 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] |