This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Contributing tree-ssa to mainline


On Fri, 2004-01-16 at 16:19, Diego Novillo wrote:
> 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.

I've now read the messages in this thread.

Diego, first, I would like to thank you for bringing up this issue and
presenting in such a balanced fashion.

Here are my thoughts on several of the key issues raised:

(1) Ada does not work with tree-ssa.

ACT does not see this as a blocking issue.  When the time comes, I think
that it's reasonable to ask that Ada people provide effort to do this
work, and I think it's also reasonable to ask tree-ssa people to commit
to helping them.  I have every confidence that will happen.

(2) G77 does not work with tree-ssa.

I do not see this as a blocking issue either, but it concerns me more,
in that nobody has come forward to say "I don't care about G77 working
with tree-ssa yet" in the same way that Dewar/Kenner have said that
about Ada.

(3) Coding standards, documentation issues, etc.

Clearly, these must be fixed before we merge the branch.  But Diego is
not asking to merge the branch *right now*; he is asking whether to
merge it for GCC 3.5.  Diego clearly understands that these issues must
be fixed before the merge occurs.  I'm sure that with concentrated
effort these issues could be fixed in the next few weeks on the branch.

(4) Mergin piecemeal vs. merging wholesale.

I think that if we decide to merge tree-ssa into the mainline for 3.5,
then it should be done wholesale.  If we do not decide to do that, it
might make sense to merge some of the changes in piecemeal.  But, I do
not think we should revisit the entire design space at this point.  I
have a very high confidence in the key tree-ssa architects to make good
decisions about the architecture, and all the evidence is that they
have.

(5) If we don't merge tree-ssa into 3.5, what will be in 3.5?

I'm not sure -- but I am sure there will be good things.  Apple is
working on compile-time performance improvements, and maybe
Objective-C++.  There will be new targets and other back-end
improvements.

Now, here are a few thoughts not relating so directly to particular
issues already raised.

(A) Ultimately, we want tree-ssa not because it is modern, but because
it provides user-visible improvements.  It's the better performance of
generated code, better compile-time performance, better language
support, and fewer bugs that our users are after.  To me, at this point,
it sounds like tree-ssa has the potential to help with all of those
things, except better language support.  But, it doesn't sound to me
like it has *realized* that potential in a sufficiently monotonic way. 
There are improvements in some areas, regressions in others.

(B) The new C++ parser is a fair analogy, although clearly the new C++
parser was a much smaller piece of work.  It is only about 15,000 lines
of code.  It only affects C++.  It's not nearly as risky to the overall
project as tree-ssa.

Therefore, my feeling is that tree-ssa is probably not ready for GCC
3.5.  My instinct is that we should try to get a GCC 3.5 release out on
something much more like our stated devlopment schedule, while tree-ssa
matures.  At the rate that has been happening, I would be astonished if
it weren't ready for GCC 3.6, especially if effort is invested in
dealing with the documentation issues and existing regressions.  I would
suggest that we focus less on adding new stuff and more on getting the
bugs out, improving the compile-time performance, and doing what can be
done to remove the RTL optimizers.  Waiting for GCC 3.6 gives gfortran
time to become a stronger replacement for G77, and for Ada to port to
tree-ssa; doing those things are benefits, even if not essential.

However, this is my preliminary opinion.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]