proposal for compilation unil wide alias analyis

[Jan Hubicka]

> David Edelsohn wrote:
> 
> >>>>>>Mark Mitchell writes:
> >>>>>>           
> >>>>>>
> >
> >Mark> The Laffer curve argument (we can remove so much code in the 
> >optimizers Mark> so quickly that generating the code will actually be 
> >faster) seems to me Mark> like it is one that should be proven 
> >experimentally before we commit to it.
> >
> >	The argument that running some simple optimizations at -O0
> >decreases the amount of intermediate code and improves the compilation
> >speed of a compiler is proven experimentally by the IBM XLC Compiler.
> > 
> >
> >That is exactly the technique that XLC uses, with extremely careful,
> >empirical tests of which fine-grained optimizations should be enabled to
> >produce the best compilation performance[1].  We need to test that such a
> >technique has a beneficial effect on GCC, but there is no question that
> >the technique can be effective.
> > 
> >
> Agreed on both points -- both that it can be effective, and that we need 
> to demonstrate that it works with GCC.  I think we want to avoid 
> committing to (say) making the tree->rtl expanders accept only SSA-form 
> GIMPLE until we can demonstrate that it will be a compile-time win to do so.

Only experiment in this direction I made so far was to build CFG at -O0
unconditionally and do tree cleanup_cfg before expanding (this was
needed for the CFG transparent RTL expansion task).  The results were
about 4% speedup on combine.c compilation times. The speedup ranged from
noise to 8% on real world testcases I tested even tought the tree
cleanup_cfg is surprisingly expensive (ie doing 7 RTL cleanups accounts
together 1/4th of time of the single tree cleanup, any idea why?)

I believe that moving expanders from generic to low gimple will be
performance win just by simplifying the whole task and reducing the
abstraction penalty we pay right now.
I don't feel 100% convinced about SSA, but it might be easy experiment
now on th emainline.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
>