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: "David S. Miller" <davem at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, <mark at codesourcery dot com>
- Date: Wed, 15 May 2002 03:03:35 -0400 (EDT)
- Subject: Re: GCSE store motion
On Tue, 14 May 2002, David S. Miller wrote:
> From: Daniel Berlin <firstname.lastname@example.org>
> Date: Wed, 15 May 2002 01:50:37 -0400 (EDT)
> I had too much fun funking around with hard to track down alias problems
> the last time i spent a month trying to improve and fix the RTL version.
> It's rather easy to fix what's there now, but it doesn't do anything
> (really. It shows 0% difference on benchmarks), except for whatever
> special case it's currently designed to handle.
> So i'm out.
> If store-motion is useless and something that really does the
> job it is trying to do is "in the pipline", why don't we
> just delete the store-motion GCSE stuff?
It's not useless in general, it's useless in the current form, except for
the special case of stores to symbol_ref's killing stores to
symbol_ref's inside loops (IIRC). One could extend it, and it's easy in
terms of store motion code, but hard in terms of tracking down bugs
elsewhere (particularly, aliasing) that affect your
The "in the pipeline" SSAPRE works at the AST level (it's on the
Thus, it can't be run after spill code generation or anything.
On machines where we spill frequently, good store motion would be very
useful at the RTL level to run after spilling.
I can't think of other reasons we would introduce lots of optimizable
stores in RTL other than spilling.
So you could be quite right, and that, for non-x86 architectures, it
eventually won't make sense to run store motion at the RTL level.
It doesn't make sense to delete it now, however, since the speed at which
i work on SSAPRE will be slowing down soon as I start my summer internship
as a law clerk.
But, if it's not useful by the time SSAPRE can do store motion, it
would likely make sense to delete the code, even if SSAPRE is still only
existing on a branch.
> If we are going to keep the store-motion stuff, we have the problem
> that the person who knows how to fix it is not willing to do so.
There are others that know how to fix it.
And improving it is conceptually easy.
And hey, maybe all the alias work that was done a few months after i last
spent moons fixing and improving store motion have gotten rid of the bugs
i ran into.
It's quite possible i'm now incorrect, and you won't run into the fun i
But I'm not going to promise something i'm not 100% positive i can
deliver. Having tried fixing and improving store motion once, i'm not 100%
positive i could fix it without getting so frustrated i burn out
for months. In fact, i'm not even 50% positive.
Given that, and the fact that i have no deadlines, i'm trying to
spend time on that which i think will improve gcc's compilation speed,
memory usage, and generated code the most. (with the occasional side trip
to improving debugging information, particularly for optimized code).
> So we have this regression on the mainline with no resolution.