This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCSE store motion
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>, Roger Sayle <roger at eyesopen dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "David S. Miller" <davem at redhat dot com>, Andreas Jaeger <aj at suse dot de>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 15 May 2002 09:45:45 -0700
- Subject: Re: GCSE store motion
- References: <Pine.LNX.4.44.0205151154080.24022-100000@dberlin.org>
> I "claimed" it wasn't doing anything because SPEC95/2000 runs show it
> making no improvement whatsoever.
I'm not knowledgeable about this particular optimization, but Sassan
Hazeghi, a very experienced compiler engineer and manager, recently
provided me with the following sensible metric:
If the optimization makes the compiler go slower when compiling itself,
it ain't worth having.
The colorful American colloquialism is mine; Sassan is much more
articulate.
It's not that this is a hard-and-fast rule -- and it certainly wouldn't
apply to a compiler that had no optimizations yet! -- but for a
relatively mature optimizing compiler it seems a decent rule of thumb.
If your new optimization pass makes the compiler bootstrap 2% slower,
well, then, it's a) pretty expensive, and b) not making things run too
much faster. If it were really a big win, the compiler itself should
run faster.
Now, I know all about how compiler's aren't representative test cases,
and all about how certain optimizations are big wins for certain other
programs, and so forth and so on, but there's an idea in there. There's
certainly no point in having an optimization that a) introduces risks,
and b) increases compile-time, if it doesn't provide measurable
improvements on real code.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com