Re: Last alignment change for MEM tracking

[Jan Hubicka <jh at suse dot cz>]

> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> 
> > This large change completes (modulo bugs) the alignment changes that were
> > the driving force behind the MEM tracking changes.  It removes the ALIGN
> > parameter from many more functions and uses the value from the MEM instead.
> 
> Hi Richard,
> 
> This patch, and the preceding patches in the sequence, seem to be
> making (when taken together) major changes to GCC.  The new
> development process requires that major changes be first made on a
> branch, where they can be tested on multiple platforms, before being
> merged in; and major changes cannot be merged in during certain
> periods relative to a release.

Actually speaking about branch.  Is there some plan how merging of code from
branches will look like?  The release schedule gives relativly short period
of time for branch merging and moves a lot of code to branch.

We currently do have very active ast-branch, new-regalloc, Jeff is working on
Midlevel RTL/SSE and I've recently created the cfg-branch, as disussed earlier.
(I've put the information about it to the web pages soon).  I expect all these
branches to make huge progress till 3.1 branching.

I am working on gcc since 1997 and I must say I don't remember any such huge
merger to happen and I do remember number of headaches with even smaller
mergers - such as haifa scheduler, gcse, load/store motion, new i386 backend,
PA-64.

All these thinks needed a months (or years) of development on the trunk to
stabilize, even when they were developed, tested and worked on the branch
before.  I am just very affraid of branches to get big making it almost
impossible to do incremental merging (I did incrementail merging with x86-64
port that were IMO relativly fluent.  I attempted to do the same for CFG work
that did run into similar problem Richard is facing now - the patches worked
all together but during merging I run into ordering problems and cleanups
causing massing mainline breakage and bringing me lots of sleepless nights).

I believe this has been due to nature of change - while x86-64 port is well
localized piece of code, while CFG development changed number of internals of
gcc and it is really dificult to catch all dead ends.
The other hand "big" merging is dificult too (it happent to subreg-byte patch
IMO that went in as single piece after few years).

I am now stayin in front of decision how to proceed on cfg branch.  I've made
the BB duplication code that appears to work now, I made the superblock
formation and want to continue slowly to loop peeling and unrolling on the CFG.

Problem is that tracer do have performance problems as code duplicating causes
number of pseudos increase liveranges or become global.  The current code
(loop test duplication/unrollin) do handle it it's own by creating pseudos.
I can do that or write pass that do it at it's own.  I made it as webizer pass.
It is much stronger, but also bring problems with debug information to be
invalid.  I can write code to make debug information valid (in fact I have
it mostly complette), but the image appears to run into big amount of changes
depdendent on each other.

Has been the procedure of merging disucssed?  What is the experience with
marging in the Redhat/Codesourcery tree?
It would be shame if the branches slipped 3.2 release just because of lack of
manpower for reviewing. It also can be shame if 3.2 got sigificantly
destabilized and has been delayed as it happen to 3.0.x

Honza