This is the mail archive of the
mailing list for the GCC project.
Re: GCSE store motion
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: 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 13:02:03 -0400 (EDT)
- Subject: Re: GCSE store motion
On Wed, 15 May 2002, Roger Sayle wrote:
> > 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).
> Hi Dan,
> You'll also be aware of the "Store merging" section of the "Optimizer
> inadequecies" page, http://gcc.gnu.org/projects/optimize.html#storemerge
> Although store motion isn't particularly functional at the moment, it
> provides a framework for further GCC improvements in the future.
But nobody has any plans to improve it, it's been bitrotting since it was
In fact, it was introduced somewhat broken due to merge botches.
It wasn't until I looked at it 6 months after it was introduced that these
merge botches were even noticed.
Not that I blame the person who committed it or anything, i'm just
pointing out evidence that nobody even looks at it.
> I'd agree that perhaps is should be in -fexpensive-optimizations, but
> I'm not convinced that its broken.
If store_ops_ok was fixed, i'm sure it's not broken.
If it wasn't, i'm not.
I don't believe it was fixed, but my memory is fuzzy.
If it's not fixed, because of how non-functional it is, it's amazingly
difficult to come up with test cases that show it.
> As you point out in your commentary
> of its deficiencies, it pessimizes const/pure functions etc..., but
> these don't affect the correctness of the code, just decrease the number
> of places this optimization is applicable.
When the number of places the optimizations is applicable approaches 0,
the optimization should be disabled.
I've not suggested we *remove* store motion until it is superceded.
I do think it should be disabled, as it just wastes time.
Or, as you say, move it to -fexpensive-optimizations.
This would let people who want to improve it, improve it such that it is