The tuples branch was scheduled to merge last during stage 1 (21/Apr).
At this point, it will be impossible for the branch to be ready for that
date. The current status is (http://gcc.gnu.org/wiki/tuples):
- The C front end is bootstrapping. The failure rate in the testsuites
is in the 2-4% range.
- We are close (~3 weeks) to having the C++ and Fortran FEs
bootstrapping.
- A good number of passes have been converted (55%) or are in the
process of being converted (70%). The conversion process is usually
a matter of 1-2 days. The passes that I expect may be problematic
are PRE and FRE, but not overly so.
- Two big items left to convert are mudflap and OpenMP (which Aldy is
finishing up).
- We continuously test the branch on ppc, x86 and x86_64. Backend
conversion is usually a matter of a few hours.
The biggest constraints we have for tuples is that we absolutely must go
last in the merging order. Going first would be convenient for us, but
it would mess everyone up (particularly things like the openmp3 branch).
Although it's not crucial for tuples to go in GCC 4.4, we would prefer
not to carry all this baggage around for LTO.
At the rate that we are currently progressing, I estimate that it will
take us around 5-7 more weeks to finish all the conversion.
So, I see a couple different scenarios that we may want to consider:
1- Push back and tell us to come back at the next stage 1. This is
certainly the easiest for everyone else, and will create a few
challenges for us on the LTO branch.
2- Once bootstrap is working for the major languages and targets, merge
and finish fixing remaining passes during stage 2. Pass conversion
is highly mechanical, so I don't consider it risky for stage 2
stabilization. We will be at this point in the 5-7 weeks I mentioned
earlier.
Merge metrics: the branch has one main goal: strict API and data
structure separation between GENERIC and GIMPLE. We achieved this at
the statement level, though operands are still represented as trees.
The new API is reportedly cleaner and we think this will make things
easier for LTO and pass writing in general.
A secondary goal was to provide a more space-efficient data structure
for representing statements. The idea is to provide a better foundation
for GIMPLE streaming in LTO. I don't think we will see huge savings in
terms of memory utilization (the projections were in the high single
digit), because statements are not actually a big part of the IL
(symbols, pools and debug info are pretty big). We still need to do
measurements here, but they are a bit hard to perform now.
I am content if the memory utilization remains the same and I will be
very surprised if it goes up (modulo bugs or implementation
boneheadedness, which should be easy to fix).
A third risk that we need to analyze are the delays that other branches
will present (they need to be converted too).
Does any one see other risks and/or scenarios we could consider for the
branch?
Thanks. Diego.
