This is the mail archive of the gcc@gcc.gnu.org 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 Tue, 14 May 2002, David S. Miller wrote:

>    From: Daniel Berlin <dberlin@dberlin.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  
results. 

The "in the pipeline" SSAPRE works at the AST level (it's on the 
ast-optimizer-branch).

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 
did.

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.
> 



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