This is the mail archive of the
mailing list for the GCC project.
Re: GCSE store motion
- From: law at redhat dot com
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Roger Sayle <roger at eyesopen dot com>, gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, "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 11:35:10 -0600
- Subject: Re: GCSE store motion
- Reply-to: law at redhat dot com
In message <Pine.LNX.firstname.lastname@example.org>, Daniel Berlin writes:
> I am completely for disabling optimizations on the mainline that do
> nothing but waste time in their current state (though even a 1%
> improvement might be arguably worth it).
> One would imagine if it's such a functional optimization, it
> would at least move or remove greater than 2 stores during
> during bootstrapping gcc.
> There are plenty of stores to be moved/eliminated.
> But it doesn't.
While it hasn't helped with GCC bootstraps or stuff like SPEC; the
current incarnation of load/store motion was designed to deal with
a set of problems found often by a class of Red Hat's customers.
Those customers really do write code which, for example, has
global variables as loop indices.
The fact that it's not useful for spec, gcc bootstraps, etc is more
a failing of not making the code general enough in the kinds of memory
references it tracks. The underlying algorithms are sound, we're just
not exposing the larger set of memory references to the optimizer.
Be very careful claiming that an optimization is a waste of time because
you have not seen cases where it is useful.