Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka <hubicka at ucw dot cz>]

>     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.

However Ada is not the only language having checks.  In some extend,
Java has the array bounds too.  If the value range propagation pass were
available, Java would take benefit of it too.

In the ideal world, where both Java and Ada used GCC trees for
intermediate representation and gimple based optimizers were ready, the
expenses for expanding bounds checking into gimple form would be much
lower and thus it may be viable to implement gimple based value range
pass that would elliminate need to do the same in Ada and Java with no
(or very little) performance cost brought by abstraction.

For me, major benefit of tree-SSA is to design such interfaces so both
frontends and optimizers may benefit from this.
But this definitly belongs to the hypotetical benefits category for you.
> 
> 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.

No, it is not language dependent, it is about generic highlever
optimizations.  There definitly are C, C++ and Java testcases.

I just wanted to point out that it is easier to find real world
testcases for C++, than C and that I believe if there were just C++/Java
testcases, it would be enought to qualify the change.
> 
> 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?

The trees are lowered early, but the main idea is that the lower
form preserve all the information relevant to optimizers.  This is
unlike RTL where we lose good part of type information and for instance
semantic on overflow.
The lowering can be seen as kind of bringing trees into more regular
form so they are easier to optimize, not throwing away high level
details for benefit of target specific details as done on RTL level.

Honza
> 
> 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.