Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo <dnovillo at redhat dot com>]

On Fri, 2004-01-16 at 20:51, Kaveh R. Ghazi wrote:


> 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.
> 
Very good point.  Thanks for bringing it up.  My original goal when I
started the project was very simple: modernize GCC's optimization
infrastructure.  To me that meant SSA, mostly because that's what I
brought with me from my University years.

Over the years GCC has done very well considering the ad-hoc nature of
most of its algorithms.  I mostly wanted for someone with knowledge
about optimizers in general and no knowledge of GCC, to be able to find
its way without much trouble.

> 1.  Better codegen from new and improved optimizations, some easier or
>     only possible in an SSA framework.
> 
The one example that, not surprisingly, comes to mind right now is SRA
(scalar replacement of aggregates).  It allows some optimizations that
apparently C++ users have been asking for a long time.  It eliminates
the need to commit structures to memory too early.  See PR12747 for
details.

The infrastructure also allows vectorizing transformations such as the
ones being planned for the LNO sub-branch.  That is still in an early
stage of development, so if the requirement is to have that in place
before merging, then we should just have this talk some other time.

We are close to the point where we can start disabling some parts of RTL
passes, which should provide compile-time improvements without run-time
regressions.  Jeff Law and Andrew Macleod have been working on that.

My original goal has almost been achieved.  We now have an
infrastructure in place that has many of the features needed to
implement global optimizers:

      * A well-defined language-independent IR (GIMPLE)
      * CFG and an API for manipulating it.
      * Type-based and points-to alias analysis.
      * An SSA form and related functionality to do data-flow analysis.
      * A pass manager to allow plugging in new transformations at will.


> 2.  Deletions of major gnarly old parts of GCC which would make
>     maintenance easier.
> 
This is in progress.  Though some progress has been made, particularly
in the areas of interfacing front ends with the optimizers.  In the
branch we have single points of contact between parsers and the
optimizer proper, for instance.

> 3.  Deletions of superceded RTL optimization passes which would make
>     GCC faster.
> 
Again, in progress.  I should add that even though we haven't yet
removed RTL passes, things like bootstrap times are only 2% slower on
the branch.  More work is needed in this area and in reducing memory
consumption.  This could be considered a blocker.


> 4.  New languages (i.e. g95, or whatever we're calling it now.)  What
>     works and what's left?
> 
I will defer to Toon Moene, Steven Bosscher or Paul Brook to answer this
one.

> (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.
>
No.  Not my style.  Since my initial posting in Feb'01 I've always
wanted only one thing: modernize GCC's optimization infrastructure.

> 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.
> 
No.  In my mind, this was never a research project.  After all, we are
only teaching GCC to do the things that compiler books have been telling
us for more than 15 years.


Diego.