Re: [RFC] Contributing tree-ssa to mainline

[Jan Hubicka <hubicka at ucw dot cz>]

>     So we've missed the required factor of 2 on this test case by 0.8%.
>     Since that seems likely to be in the relm of measurement error, I
>     think that should qualify.
> 
> I agree.
> 
>     With a bit more work unwravelling C++ front-end obfuscation, I would
>     expect the 10-20% to be visible on just about any object abstraction
>     test case.  Particularly for any object that has more than one field,
>     and thus can't benefit from rtl addressof.  That seems like it should
>     be a large enough class to qualify.
> 
> Likewise.
> 
> However, it would be good to see cases of both of the above for C as well as
> C++: if the gain is just C++, one could argue that the most appropriate place
> for such code is in the C++ front end.  (There are Ada-specific optimizations
> in the Ada front end, for example.)

While it is possible to find/construct C testcases with large
abstraction penalties, this is not as common as for C++ or other more
modern languages.

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.  I don't think re-doing optimizations in each
frontend is good design decision.

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.

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

Honza
> 
> The tree-ssa infrastructure is supposed to benefit *all* languages.  If
> benefits can be shown in C, they will clearly apply to all languages.  But
> that's not true for C++.