Re: [RFC] Contributing tree-ssa to mainline

["Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>]

 > > > 3- There are several bug reports opened against the branch (92 as
 > > > of today).
 > > 
 > > I believe the general policy, not specific to tree-ssa, is that
 > > everything that is a regression of a branch compared to mainline
 > > blocks the merger of that branch.
 > > 
 > > (This is the direct analogon to our patch rules, where a patch with
 > > known regressions must not be applied. In fact, merging a branch is
 > > a large patch.)
 > 
 > And the branch merger has the additional requirements of no
 > regressions in the testsuite on three different CPU targets.  For this
 > major change I think testing with no regressions on all primary
 > release platforms (as in the 3.3 release criteria if no later version
 > is available, but allowing later versions of the operating systems
 > since many of those listed are obsolete, and e.g. variation in the
 > particular GNU/Linux distributions used with a given target triplet)
 > would be appropriate - that covers six CPUs.
 > 
 > How does compile-time performance compare to mainline?
 > 
 > I take it you believe that all the coding conventions are properly
 > followed on tree-ssa?  For example, all command-line options added are
 > documented, including the details of what is enabled at what -O levels
 > (listed both under the options themselves and under the -O options);
 > the documentation of trees is up to date and covers everything new
 > about them; sourcebuild.texi appropriately covers the gfortran library
 > and the tree-ssa testsuites; passes.texi gives an accurate description
 > of how the compiler now operates, documenting the tree-ssa source
 > files appropriately; no files have copyright notices referencing "GNU
 > CC".

I would echo Gerald and Joseph's comments about regressions and
documentation.  (However IMHO, it's up to frontend maintainers to
upgrade their bits, so Ada and g77 not working is okay with me.)  I
also think it's fair to accept the work with some regressions as long
as we receive assurances that they'll be addressed full time and
quickly, like Mark has been doing with the new c++ parser.


But something is missing from Diego's call for discussion.  I think we
should at least expect a more thorough status report (beyond the SPEC
numbers which appear to be a wash.)  This should include tree-ssa's
original goals and how close we are to meeting them.

Over the last year in the mailing lists and in presentations at the
conference last May, my understanding was that tree-ssa promised many
good benefits, including:

1.  Better codegen from new and improved optimizations, some easier or
    only possible in an SSA framework.

2.  Deletions of major gnarly old parts of GCC which would make
    maintenance easier.

3.  Deletions of superceded RTL optimization passes which would make
    GCC faster.

4.  New languages (i.e. g95, or whatever we're calling it now.)  What
    works and what's left?

(If I've missed any suggested benefits, please add them.)


Now I know when a radical project is in it's infancy, from an advocacy
perspective, it was in your interest a year ago to promise tree-ssa
would create world peace, cure cancer, etc.  And it's quite possible
we'll only meet some of these goals only partially and yet still feel
it's worthwhile to accept the work.  But I think it fair that you
describe where we're at and whether all of these are realistic or not.
Or maybe you've discovered you were too conservative and the promise
of the branch is even greater than originally described.  Either way,
we need this information.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu