Re: Compilation performance comparison of 3.5.0 and TreeSSA trees on MICO sources as requested in: [tree-ssa] Merge status 2004-05-03

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Wed, May 05, 2004 at 10:14:16AM -0400, Diego Novillo wrote:
> On Tue, 2004-05-04 at 21:08, Richard Kenner wrote:
> >     The gimplification process tends to create extremely bloated RTL.
> > 
> > Why?  I would expect it to produce exactly the same RTL as that produced
> > before tree-ssa if no optimization is done.
> >
> Mostly because of the breaking down of expressions into small trees,
> which are friendlier to the RTL expanders.  That's the reason we have a
> tree recombination pass at the end of tree optimization.
> 
> Of course, most of the bloat comes when you don't allow the tree
> optimizers to run.

What our users want at -O0 is fast compilation times and excellent debug
support.  The latter means that all entities defined at source level
appear to have their expected values at any place where the gdb user can
set a breakpoint or single-step to (when stepping by lines, not
instructions), and that tools like gcov show results corresponding to the
original source structure.

Optimization passes that run quickly and reduce the size of the trees,
without interfering with debug-ability, are likely to make compilation run
faster (less data to process, fewer instructions to be processed by the
assembler and linker), so I think that tree-ssa should do them.  It's the
only obvious way to get rid of compile time regressions at -O0 that I can
see.