This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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,
> 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 
generally useful.

> Roger
> --

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]