Re: [RFC] Contributing tree-ssa to mainline

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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.

My view is that I don't see this as something we can schedule (or even
decide) in advance.

As I said, I see the nature of the tree-ssa project as research rather than
development.  Nobody seemed to understand what I meant before, so let me
clarify because it's part of my answer to how I view the above issues.

In conventional software development (say for a game, avionics, or a linker),
you have a specification and well-defined process for taking that
specification and turning it into code.  You have a quite good idea when you
start how things are going to go and there are simple metrics for seeing how
far you are in the process.

In contrast, in a research project, what you start with is more a goal than a
specification.  You usually have an idea of how you're going about achieving
that goal, but the bulk of the project is in fleshing out the details of how
to achieve the goal rather than a straightforward programming project.  When
you start the project, you don't know in advance how things will go in detail
or even if you'll be able to achieve the goal.  There's usually no simple way
of seeing how far you've gotten in the project because of the lack of a good
metric: a long time may go by with no progress towards that goal or there
might be a "eureka moment" when great progress is made suddenly.

So I don't think we can or should ever answer in advance the question of when
(or even if) the tree-ssa branch will be ready, but instead work on defining
what criteria we'll use for making that determination.

In my mind, part of that criteria would be the transition of the work from
research to more conventional development, which means that it has passed the
experimental stages where people are seeing what does and doesn't work and
what works best.  But most important in my mind is having the work meet it's
goal.  So the question then becomes what *is* that goal.

Obviously, it's up to the people working on the project to clearly state what
they see as the goal and perhaps provide metrics to see if it's being met,
but roughly speaking I see the goal as making major improvements in
optimization by setting up an infrastructure for doing optimizations at a
high level.  I do *not* see the setting up of that infrastructure as itself a
useful benchmark: it needs to be shown that it actually *helps*.

The issue of whether or not the RTL optimizers can be eliminated or
simplified has been discussed a lot.  One argument would be that we should be
able to answer those questions before considering tree-ssa to be
"operational", but I'm not sure how strong an argument that is.

>From a performance point of view, if all we do is *add* more optimizers
rather than replace some, the burden on those optimizers is higher since they
will increase compilation time.  On the other hand, doing more optimization
earlier will speed up the RTL optimizers by giving them less to work with, so
the strength of that concern is yet to be demonstrated.

My feeling is that "success" would be in showing at least one class of code
where we see very significantly better code (at least a factor of two) and we
see significant (around 10-20%) performance improvement in a larger class of
test cases.  If we leave the RTL optimizers in place, then we should *always*
be producing better code than without tree-ssa: any situation where we don't
strikes me as demonstrating something fundamental that needs more work; if we
replace some RTL optimizers, then I can see relaxing this standard if we see
our way to fixing those performance regressions without major redesign.  I
don't see compilation performace as being a major driver here unless it's a
major degradation.

I understand that the longer we keep the separate branch the more maintenance
cost we have, but the opposite error would be far worse: if it turns out that
the tree-ssa approach is not achieving its goal and we decide to
significantly postpone it (or even that it's not viable), backing it out in
the presence of lots of other unrelated work being put into the tree is a
*very* difficult prospect.  So I'd argue for a very conservative criteria for
merging it into the mainline.