This is the mail archive of the
mailing list for the GCC project.
Re: Compilation performance comparison of 3.5.0 and TreeSSA trees on MICO sources as requested in: [tree-ssa] Merge status 2004-05-03
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: dnovillo at redhat dot com, gcc at gcc dot gnu dot org, kenner at vlsi1 dot ultra dot nyu dot edu
- Date: Wed, 5 May 2004 10:37:38 -0700
- Subject: Re: Compilation performance comparison of 3.5.0 and TreeSSA trees on MICO sources as requested in: [tree-ssa] Merge status 2004-05-03
- References: <20040505165138.DCC14F2965@nile.gnat.com>
> > 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.