Re: [RFC] Contributing tree-ssa to mainline

[kenner@vlsi1.ultra.nyu.edu (Richard Kenner)]

    On the other hand, if Ada can really do the job of its check
    elimination so much better than a generic optimizer, fair enough.  But
    range check elimination using VRP is a sufficiently generic problem
    that many languages will benefit.

I agree.  I wasn't arguing against VRP or saying that it would not be useful
in eliminating range checks, just that there are language-specific tests that
can more easily be done in the front end that eliminate the need for
sophisticated optimizations like that.

The GCC approach has always been to do as many optimizations as possible at
all levels: we do constant folding at both the tree and RTL level.  This is
done not just to avoid the risk of missing an opportunity, but because the
earlier we do an optimization, the less work the lower level optimizers have
to do and that improves compilation speed.

I see it as the same with checks and VRP: certainly VRP ought to be
implemented and certainly it will eliminate some checks, but that does *not*
mean we shouldn't implement a check-elimination pass in the Ada front end
that uses static semantic information that language-independent code doesn't
have access to.  The reasons are the same as above: not only does it avoid
the risk of missing an opportunity, but it creates less work for subsequent
passes to do.

    And of course there are other things: escape analysis, for example.
    Sure, I could do that in the Java front end, but I'd rather not.

I don't know enough about escape analysis in Java to offer any opinion as to
whether it's appropriate to have such in the front end, but I believe that if
it's easier to do at that level, it should be done there even if other
optimizers could also catch some cases.

A lot of the strategy for Ada was not be concerned about generating a lot of
code and to assume that GCC would optimize all the junk away. This strategy
has worked remarkably well, but does cause worse code in many more cases than
we'd like to see due to some notable failures in language-independent
optimization not being able to optimize some cases.  There's reason to
believe tree-ssa will do a better job, but the best job would be produced by
not generating the junk in the first place.

I believe the reason for GCC's great success in the past has been its
strategy of doing optimizations at all possible levels and I also believe
this will be reason for its success in the future.  So I see tree-ssa as an
another set of optimizers, but not one that will remove the need for having
any optimizations in the front end nor certainly remove the need for RTL
optimizers.  I don't think this is or should be a goal of the tree-ssa project.