This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Contributing tree-ssa to mainline
- From: Scott Robert Ladd <coyote at coyotegulch dot com>
- To: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Sat, 17 Jan 2004 09:30:20 -0500
- Subject: Re: [RFC] Contributing tree-ssa to mainline
- References: <email@example.com>
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.
Thank you for raising this topic!
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.
I would like to see tree-ssa become mainline as soon as possible. I see
no point in putting major work into gfortran and gomp if that effort is
going to continue to be speculative, nor do I see an easy way to
implement those features (Fortran 95 and OpenMP) in the current mainline.
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(!)
The problem only grows worse with time. It's time to fish or cut bait.
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.
The Ada issue is an important one, I think. I don;t know the issues very
well; has anyone even considered how the existing Ada compiler might be
integrated into SSA?
3- There are several bug reports opened against the branch (92 as of
All branches have bugs. Put SSA in mainline, and we might find more
people to work on them.
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).
I'll try to put together some numbers this weekend based on my
independent test suites.
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
As far as I can see, delay gains us nothing but delay. What, precisely,
would go into a non-SSA 3.5, beyond bug fixes? Waiting for 3.6 would
only increase the difficulty of moving SSA to mainline due to increased
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
We would have a working Fortran 95 compiler.
OpenMP would get more attention, and might actually see the light of day.
I've spoken to some people who might contribute to OpenMP, but who think
tree-ssa is too tentative to risk wasting effort.
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.
A good point. Again, the sooner we start, the sooner we're done, and the
less that needs to be reworked.
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing