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

[Jan Hubicka <jh at suse dot cz>]

> 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

Are there so many PR on unit-at-a-time?  I hope I've fixed all of them
today, but I found only 5 of them so far in the bugzilla and some of
other bugs we noticed while building the packages on hammer branch where
I backported it for more testing.
We are about to build all the SuSE Linux pakcages with unit-a-t-atime so
it should get enought testing in a week or so.

> 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

Current rtlopt branch has bit too many of unrelated changes in it
as some of changes we did in cfg branch didn't get into 3.3, where moved
to rtlopt-branch and they didn't get into 3.4 too.
I am thinking about creating 3.4 based branch once 3.4 freezes and move
relevant bits there together with some cleanups after merge headachaes we
had on rtlopt branch.

Honza
> 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
>