From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24328 invoked by alias); 16 May 2002 21:19:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24252 invoked from network); 16 May 2002 21:19:28 -0000 Received: from unknown (HELO www.dberlin.org) (151.203.29.129) by sources.redhat.com with SMTP; 16 May 2002 21:19:28 -0000 Received: by www.dberlin.org (Postfix, from userid 501) id 0990B4C8ED9E; Thu, 16 May 2002 17:19:28 -0400 (EDT) Subject: Re: GCSE store motion From: Daniel Berlin To: law@redhat.com Cc: Mark Mitchell , Roger Sayle , "gcc@gcc.gnu.org" In-Reply-To: <5680.1021567164@porcupine.cygnus.com> References: <5680.1021567164@porcupine.cygnus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 16 May 2002 14:44:00 -0000 Message-Id: <1021583967.27891.112.camel@dberlin.org> Mime-Version: 1.0 X-SW-Source: 2002-05/txt/msg01382.txt.bz2 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" > > 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