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]

GCC 3.5 Plan, Take 2



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

There have been a lot of comments about the GCC 3.5 plan I posted.

It's clear that there are a set of improvements that people want to
incorporate before before GCC 3.5.  That's not surprising; at any time
that we go to make a release, there will always be more improvements
that we could incoporate if we waited just a little longer.  Hence all
the articles about software feature creep in the management
literature.

It's also clear that I'm not fully aware of all the things people have
in the pipeline.  And, it's clear that I can't make good decisions
without knowing that information.  Below, I'll discuss how I want to
correct that problem.

First, I will talk a bit about my goals for GCC 3.5.  

First and foremost, as with all releases, I would like to see the
benefits -- technical and non-technical -- of upgrading to GCC 3.5
outweigh the benefits of staying with GCC 3.4.x for most of those
users who might consider upgrading.  (There is a class of users for
which no major upgrade is ever a good idea.)  There are a lot of ways
to get there: better code generation, better compile times, better
language conformance, more targets, more languages, better support
from the GCC team for bugs, more support from distributors, better
error messages, fewer wrong-code bugs, a better manual, etc., etc.
There's no objective measure of all of these things, and the
definition of "good enough" varies with lots of inputs, which is why I
have shied away from lots of criteria descriptions.  I view it as my
job to synthesize comments and information from people and then,
eventually, say "OK, that's good enough, let's ship it."

We're already better than GCC 3.4 on a lot of these axes.  Right now,
we're probably losing a bit on compile-time, especially with
optimization enabled, and most people seem to think code generation is
about a wash.

I expect it to be hard to get GCC 3.5's code-generation to be
noticably better than GCC 3.4.x's across the board within a few
months.  I expect that it will not be until six months to a year hence
that we'll see noticably better code generation on most test cases.
Since I don't think that most people want to wait that long for GCC
3.5, I think we need to accept that we're shooting for code generation
that is, in general, not worse, and may be better on some particularly
high-profile cases.  In the worst case, we may even have to accept
worse code on some real cases.  If we can vectorize some loops, and
SRA provides big wins on some C++ test cases, and we're in general
pretty close to GCC 3.4, I think the release will be well-received,
given all the other improvements.

In fact, I think that breaking even would be a great result given the
switch to tree-ssa; it's hard not to be markedly worse when building a
whole new set of optimizers from scratch.  

Thus, if your opinion is that we shouldn't release until and unless
GCC 3.5 is knocking the socks off of GCC 3.4, you and I are going to
have to agree to disagree.

At the same time, I don't want to impose an arbitrary deadline that
causes us to miss substantial performance wins that we could achieve
with just a little bit more time.  

So, here is what I would like to do.  

For each project -- optimization or otherwise -- that you are working
on that you would like to have included in GCC 3.5, please send an
email *directly to me* using the following form:

  Name of Developer:

  Name of Improvement:

  Dependencies:

  [The names of other improvements upon which this one depends, if
  any.  Coordinate with the developers of these other improvements to
  obtain the names that they are using, please.]

  Description of Improvement:
  
  [A paragraph or ten explaining what you are doing, what benefit your
  improvement will have, with quantification where possible, and what
  risks your improvement will entail, and how these risks will be
  mitigated.  Warning: I will disbelieve descriptions that indicate
  that there are no risks to the indicated change.

  Be as detailed as you can be.]

  Delivery Date:
 
  [The date on which you can commit to delivering this improvement.
  Be conservative!  If this improvement is already in process, please
  say describe the current state, in terms of percentage complete and
  any testing done.  Warning: late (for a definition of "late" not yet
  determined) delivery dates may result in your improvement not being
  considered for GCC 3.5.  Warning: missing your delivery dates may
  also result in your improvement not being included in GCC 3.5, and
  I'll not be very sympathetic about extenuating circumstances.  So,
  think hard before you say "I can get this done in a week."]

If your organization has a lot of improvements in the pipeline, please
try to work together with the others in your organization, and send me
one coordinated response containing all the improvement descriptions,
rather than multiple possibly-conflicting descriptions.

I will gather these together on a web page, or pages, as they come in.
I'll accept these submissions through Sunday, August 22nd.  I'll not
be terribly rigid about someone who is on vacation this week, but I'll
not be terribly flexible either, so let's get these in, please!  

I'll then make a decision about which ones are in and which are out,
probably after contacting some of you directly for help.  After the
decision is made, I'll expect that you respect my decision, even if
you disagree.

Thanks,

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