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

I wrote:
> > 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.

On Wed, May 05, 2004 at 12:51:38PM -0400, Robert Dewar wrote:
> This is an interesting change of philosophy, but may be quite reasonable.

Just trying to be practical here.

> Once you accept that you can do non-destructive optimizations at -O0, this
> can be carried a bit further. For example, just slightly better register
> management can improve the code (it is really annoying to see a load
> immediately follow a store with the same register and memory address :-)

I'm not that concerned with the performance of the -O0 code.  I just want the
compile, debug, attempt fix, compile again flow to go faster, or at least
stop getting worse.  Any change would also need to worry about
reliability: if we have new code to do the low-cost optimizations, which
is different from what we have already, we risk having bugs at -O0 that
aren't present at -O1 and above.

> Size of code at -O0 is also an issue. When you get into a situation with
> hundreds of megabyte executables, things can get unpleasant.

Yes, I mentioned that (at least indirectly): simple optimization for space
speeds up the compiler, because there are fewer instructions to process
through RTL, assembler, and linker.