Re: GCSE store motion

[Daniel Berlin <dberlin at dberlin dot org>]

On Thu, 2002-05-16 at 12:39, law@redhat.com wrote:
> In message <23630000.1021488625@gandalf.codesourcery.com>, Mark Mitchell writes
> :
>  > 
>  > 
>  > --On Wednesday, May 15, 2002 11:38:03 AM -0600 "law@redhat.com" 
>  > <law@redhat.com> wrote:
>  > 
>  > > In message <17950000.1021482109@gandalf.codesourcery.com>, Mark Mitchell
>  > > writes:  > Dan's claim seems to be that nobody has a real-world
>  > > application that  > shows an improvement with store motion enabled.  If
>  > > that's true, we  > don't need that optimization enabled.  We can keep the
>  > > code, and use  > it when it becomes more useful, but there's no reason to
>  > > be running  > that pass.
>  > >  >
>  > >  > If, however, someone has real applications that show measurable
>  > >  > improvents -- the Linux kernel would certainly qualify -- then we
>  > >  > should rethink the issue.
>  > 
>  > > Would games on a very popular game console work?
>  > 
>  > Sure!  Do we have any numbers at all?  (I know you said it was difficult
>  > to measure...)

However, please note that *I* would only consider this very popular game
console if the port is in the FSF tree, or it helps some game console
port in the FSF tree.
I'm not sure, but IIRC, most of the game console ports don't exist in
the FSF tree. Please correct me if i'm wrong.
After all, no offense Jeff, but *I* don't care if it only helps Red
Hat's GCC customers, and not the people who use the FSF tree.  The Red
Hat customers can just use the flag or whatever .

Others may have differing views.

>  > 
>  > I think there are two issues:
>  > 
>  > 1. Correctness.
>  > 
>  > 2. Efficacy.
>  > 
>  > There seems to be some debate on (1), but assuming that the optimization
>  > is correct, we're down to (2). 

> As long as the optimization doesn't
>  > take unreasonably long to run, and as long as it helps some real programs
>  > without hurting most of them, we should have it.
> Given Toon's reference -fno-automatic or whatever it was, we can probably
> address #2 by running spec with that switch -- once with LSM, once
> without LSM.
You mean SM, we aren't talking about LM.

> 
> Maybe the folks at SuSE could cover that since it seems they have a
> good infrastructure for this kind of thing.
I've already done it for SPEC95's fortran programs.
Without -fno-automatic, it removes no stores on any of the fortran
programs.
With -fno-automatic, it move quite a few, but all of the programs
actually take *longer* to run (IE it's a pessimization).
-fno-automatic -fno-gcse-sm actually speeds a few  back up, but not to
the speed without -fno-automatic.


So GCSE SM is actually *hurting* us here in some cases, by a small but
consistent percentage. When it does help, it's not helping enough to
overcome the hurt it causes (it's 1%).

Looking at dumps, it seems to insert way too many stores to delete too
few.  This would be symptomatic of it thinking stores were not available
when they were, or something of the sort (causing it to insert extra
unneeded stores).
I'm hoping, anyway, because certainly, it shouldn't be slowing programs
down.
At least, one could disable the motion part, and keep the store removal
portion (it removes stores it comes across that are already marked
available, as it computes the bitmaps).

This is all non-official, running the programs multiple times by hand on
the right inputs and outputs (where needed), so don't take it as
official or anything. I'd still like to see a real run done.


> jeff