[RFC] Contributing tree-ssa to mainline

[Diego Novillo <dnovillo at redhat dot com>]

Now that we are about to enter Stage 1 of 3.5, I wanted to solicit
feedback regarding the merge of the tree-ssa branch into mainline.

First and foremost is the obvious question of whether people think that
the whole infrastructure is worth adding to GCC at all.  From what we've
discussed in the past few months, the consensus seems to be that it is. 
But I think it's important to find out if folks think otherwise.

If we decide to add SSA for 3.5, then we need to determine exactly how
we are going to go about it.  I will try to summarize the more important
points to get the discussion going.  In the following I assume that we
have decided to add tree-ssa to GCC:


1- The changes in tree-ssa are pretty big.  A quick diff against the 3.4
branchpoint in the gcc directory shows

 11558 files changed, 161996 insertions(+), 14697 deletions(-), 30494 modifications(!)

Some of that is due to the drift since the latest merge, but that should
give you an idea.  That doesn't include changes to ../lib*.


2- Ada and g77 do not work anymore.  The new Fortran 95 front end
replaces g77, though I'm not sure what's the compatibility situation. 
There is no replacement for Ada.  As it is today, it is impossible to
build an Ada compiler with the branch.


3- There are several bug reports opened against the branch (92 as of
today).


4- The branch lags in performance wrt mainline by about 3% in SPECint
and is about 4% faster in SPECfp (take these numbers with a grain of
salt, this is from my daily SPEC runs).


So, there clearly is much work to be done yet.  A very conservative view
would be to declare the branch still not ripe for inclusion and wait for
GCC 3.6.

Pros	Mainline is not disrupted with such major changes.
	We avoid a possibly lengthy 3.5 cycle.
	Other major work can go in without worrying about the new
	infrastructure.

Cons	The SSA bits stay secluded without the benefits of the
	widespread testing done on mainline.
	Other major changes may interfere with tree-ssa, slowing down
	progress in the branch.
	Benefits given by the new infrastructure cannot be used for new
 	work.


Another thing to consider is that we need to have peer review for all
the changes done in the branch.  The implementation and/or design will
need to be reviewed and may require extensive changes.

If we are going to merge during Stage1, we could either phase in all the
changes separately or just drop the whole thing at once.  For reviewing
purposes, we probably want to phase-in.  Though, we could do the review
separately and then drop the whole thing.  The are few independent
chunks in the branch (listed in precedence order):

     1. Folder changes.
     2. GENERIC/GIMPLE.
     3. tree->rtl expanders.
     4. g95.
     5. SSA infrastructure
             A. operand discovery.
             B. alias analysis.
             C. pass manager.
             D. individual passes.

2 and 3 need to go in together and are the ones that prevent Ada and g77
from working.  So, once those are in, we can't go back.

I may be forgetting a bunch of stuff.  I would like to reach a consensus
soonish so that we can plan accordingly.


Thanks.  Diego.