Re: Development plan *ducks* (Re: Loop optimizer issues)

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Op di 29-07-2003, om 00:09 schreef Zack Weinberg: 
> Steven Bosscher <s.bosscher@student.tudelft.nl> writes:
> 
> > Op ma 28-07-2003, om 22:40 schreef Zdenek Dvorak:
> >> What would be the purpose of making the changes in my private tree?  I think
> >> it is better to expose my work to other people as well.
> >
> > This is true of course; you're not going to get the required testing
> > unless development is done in public.  But in fact, with the current
> > number of branches, you're not going to get the testing if you work on
> > the rtl-opt branch.
> >
> > Just look at the gcc-testresults archive: No more than 4 test results
> > this month, all of them from phil's autocrasher, ie. one target.
> >
> > Compare that with tree-ssa, with more than 100 reported test results,
> > for no fewer than 7 different targets just yesterday.
> 
> I'd strongly encourage merging rtlopt into tree-ssa at some point,
> rather than trying to merge them both into mainline early in 3.5.
> Zdenek, is there anything else in rtlopt besides your new loop
> optimizer?  If not, perhaps you should fold it into tree-ssa now and
> continue development on that branch.

But again, then there is no simple way to test tree-ssa plain.  An
experimental is OK, but not too experimental, that's really a bad idea! 
It's not only too experimental, it's also about how to keep the tree-ssa
branch maintainable.  That could be a *big* pain.

Maybe we should consider other options?

One option is moving out the most recent new features (intermodule,
C++-unit-at-a-time, other bug-causing/uncovering patches) off the trunk
onto a branch, try to get GCC 3.4 out ASAP (ie. on schedule: ~4 months
from now), and take a few extra months for 3.5 (or 4.0? :-).  But we
already have too many open bugs, and the intermodule patch is just huge,
so this may be just not feasible/reasonable.
(BTW How many of the bugs targeted for 3.4 really are regressions?)

Another option is to open a pre-3_5-merge-branch, which would be
rtlopt+tree-ssa in their current shapes; all non-3.4 development
branches (objc-impr, etc) would be sub-brances of that.  But this
strategy (3_4-BIB) caused the release cycle for 3.3 to take 16 months
instead of 6, because everyone was working on the fancy new stuff on all
the branches.  So maybe this really is not a good idea either.

Then there's the union of the two, or just do nothing and deal with the
inevitable troubles and pains of a merge.  Any other options?

The problem is of course that all you people just work too hard ;-)

Gr.
Steven