GCC 3.5 Status (2004-08-29)

[Mark Mitchell <mark at codesourcery dot com>]

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

Asking for project submissions was certainly useful.  I got 45 such
submissions.  Henceforth, I plan to request these submissions much
earlier in the release process.

Below is a list of all of the projects received.  There are dates with
some of the projects.  Those are deliver-by dates.  If your project is
not submitted by that point, with appropriate testing, etc., we're
going to pass on it.  Some of the dates are earlier than the
submitter's estimated delivery-by dates.  I know these dates may not
be achievable.  There's no obligation on the submitter to try to meet
these dates -- but if you don't, we'll move on without you.  If the
project is submitted, but not reviewed, by that date, we'll try to get
it incorporated.  Of course, just because your project is submitted by
the deliver-by date doesn't ensure acceptance; you must still
convinvce the appropriate maintainers that your change is worthwhile.

For everything not explicitly mentioned below, Stage 3 will begin
September 5th as announced.  We'll fully enter Stage 3 on September
26th, which is one week after the latest deliver-by date below, to
give us some time to review things submitted by the September 19th
dates.  The reason that other "safe" Stage 2-ish changes will not be
accepted between September 5th and October 1st is that (a) history has
shown that such changes are often not as safe as submitters think, and
(b) there are lots of bugs to fix.  Furthermore, I believe it to be
the case that, in the timeframe in question, bigger performance wins
can be had by tuning and improving the existing code than by adding
new optimizations.

We will include projects marked for postponement until GCC 3.6 below
if they have already been submitted or make it in before September
5th, so as to be consistent with earlier announcements.

If you disagree with my decisions, feel free to send me a message
explaining why you think that the decision was inappropriate.  I will
consider your position, but you will have to be convincing in order to
change my mind.  To be convincing, make sure you quantify the win: it
you want me to believe that your optimization is worthwhile tell me
how much it improves a well-known benchmark.

-------------
Cleanups, etc.
-------------

There were a few submissions that are cleanups, or infrastructure
improvements, on which nothing else depends, and which -- according to
the submitters themselves -- do not bring substantial user-visible
improvements.  Those will not be accepted past the previously
announced Stage 3 cutoff date: September 5th.  These include:

* Immediate use integration [MacLeod] 

* Top-level bootstrap [Bonzini/Nerode]

* Automatic dependency for GCC builds [Weinberg]

* Convert RTL passes to use pass manager [Nerode/Bonzini]

These changes are all good -- but get them in before September 5th, or
hold on to them until GCC 3.6.

--------------------------------
Target/language-specific changes
--------------------------------

As a general rule, I'm going to delegate target-specific and
language-specific changes to the discretion of the appropriate
maintainers, at least until we make the release branch, and perhaps
longer.  So, for example, the Java ABI rework can go in during Stage
3, if the Java maintainers think that's OK, and the MIPS paired-float
work can go in if the MIPS maintainers think it's OK.  Maintainers,
please exercise good judgement here, and err on the side of caution.
If your port/language gets all messed up, I'll be very hesitant to
delegate to you in future.  I'm not delgating similar responsibilities
for common code (including optimizations) because the consequences of
changes there are much more far-reaching.

This delgation rule applies to the following language-specific
changes:

* Member class template as template friend (PR13495) [Lerdsuwanakij]

* GCJ BC ABI [Haley/McKinlay/Tromey]

* C90 [Myers]

* Objective-C++ [Laski]

* Add "Class <protocol>" support to the ObjC frontend [Ayers]

In addition, the SC has promised Zem that we wil get Objective-C++
into GCC 3.5.  Therefore, we will not release without Objective-C++,
unless something seems to have gone horribly awry.

This delgation rule also applies to the following target-specific
changes:

* PowerPC GNU/Linux dot-smybol removal [Modra]

* MIPS paired single support [Wilson]

* PA long conditional branches [Anglin]

* PA GNU/Linux TLS [Anglin]

* PA HP-UX Ada [Anglin]

* 64-bit PA HP-UX shared libgcc support [Anglin]

* Windows TLS/weak/shared/versioning support [LaFramboise]

This delegation rule does *not* apply to the following changes, as I
consider them to have too high a risk/reward ratio, and they will
therefore be postponed until GCC 3.6:

* 64-bit PA HP-UX DWARF2 Exceptions [Anglin]

* PA HP frame layout [Anglin]

* IA64 floating-point model [Weinberg]

* HP-UX __fpreg support [Weinberg]

* HP-UX #pragma _USE_SF support [Weinberg]

* IA64 division/sqrt scheduling improvements [Weinberg]

If these get done, and look very solid, and everyone wants them, I'll
reconsider.

-------------------------
Compile-Time Improvements
-------------------------

There were three submissions relating primarily to compile-time
improvements.  Since this has been a persistent problem, we'll allow
these changes for GCC 3.5 -- if they can get finished quickly enough.

* Fix/finish --enable-mapped-location [Bothner]

  September 19

* Edges-in-vectors conversion [Elliston]

  September 19

* General compile-time performance improvements [Weinberg]

  This project is a catch-all.  We will decide these on a per-change
  basis.  Compile-time performance is a major issue.  As in previous
  Stage 3s, and even on release branches, these changes will be OK,
  with appropriate maintainer approval -- but more localized, smaller
  changes will of course be favored over bigger changes.

--------------------
Optimization Changes
--------------------

There are a ton of these: a lot of people are working hard on a lot of
really interesting projects.  What I've done with these is selected
those that I think have the best risk/reward/timeliness tradeoffs.

* Analysis of usage of compilation unit static variables and removal
  of spurious clobbering vdef based on the information [Zadeck]

  September 12

* Use the previous project to promote non-escaping static variables
  into true ssa variables [Zadeck]

  September 19

* Vectorize unknown-loop-bound support [Golovanevsky]

  September 12

* Vectorizer peeling-for-alignment support [Golovanevsky]

  September 19

* Vectorizer additional data-references support [Rosen]

  September 19

* Linear loop transforms [Berlin]

  September 12

* Variable expansion optimization [Eres]

  September 12

* LNO branch merge [Dvorak]

  September 19

* Tree-based branch prediction [Hubicka]

  September 5 

* Tree-based profile-directed feedback [Hubicka]

  September 12

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.

* Tree-based coverage [Hubicka]

* Aliasing improvements for structure fields [Berlin]

* Value range propagation [Novillo]

* CFG-based inliner [Hastings]

* Vectorizer misaligned-loads support [Naishlos]

* Vectorizer pattern recognition support [Naishlos]

* If-conversion and vectorization of conditional code [Patel]

* SMS improvements [Hagog, Markovitch]