Re: [RFC] Contributing tree-ssa to mainline

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

    Even if tree-SSA didn't made important speedups for common C programs I
    think this is not problem as long as it is not making C worse and do
    make C++ and Java better.

Can similar cases as those shown for C++ be constructed and measured for Java?

    I don't think re-doing optimizations in each frontend is good design
    decision.

I agree that *re-doing* is not a good design decision, but it's quite often
the case that *doing* optimizations in a front-end is the appropriate design
decision.

A case I know about in Ada is check elimination.  Because the default for Ada
is enabling checking, it's quite important to eliminate checks that can be
proven not to fail.  Theoretically, a lot this could be language-independent
optimizers by value range propagation and related optimizations.  But the
front-end can do a much better job because it has information only it knows.
Moreover, by suppressing the check before generating any code for it,
compilation time is reduced.  I think this is clearly the proper place for
that optimization.

That's why I asked about this, if it's truly C++-specific: wouldn't it be
better in the C++ front end?  That's why it's important to understand how
language-independent it is.

    In longer run, with the new loop optimizer or profile driven inlining,
    we will see considerable benefits for C programs too, but I would
    prefer this to not be blocker for tree-SSA acceptance.

I would.

    The optimizations tree-SSA implement right now are just essentials to
    get more work in this area done.

I'm not suggesting not getting any work done: there's active development work
being on it now and I'm all in favor of it being continued.

However, I'm not as willing as some people to simply accept the argument that
this will lead to "considerable benefits" due to what are essentially
theoretical arguments.  I'm a pragmatist: I'd like to *see* those benefits.

I'd like to see examples of some of these optimizations that provide
"significant" (leaving that undefined for the moment) benefits for all
languages before accepting that the tree-ssa structure is as beneficial as
its proponents argue.

One specific concern I have is the issue of when to lower.  I admit I haven't
been following the project closely, so please feel free to correct me if I'm
wrong, but my sense is that lowering of the level of the tree is now being
done very *early*.  That seems to me to be potentially incompatible with the
argument that doing such things as loop optimization at the tree level can
use higher-level information: are we preserving such information?

As I said, perhaps I misunderstand what's going on, but if I don't, I think
the above is the critical issue and the design space of when to lower needs
to be resolved by actually demonstrating some of the hoped-for high-level
optimizations. I would not be comfortable merging tree-ssa until that level
of design issues have been settled.