From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16823 invoked by alias); 12 Dec 2002 05:33:23 -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 16772 invoked from network); 12 Dec 2002 05:33:22 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 12 Dec 2002 05:33:22 -0000 Received: from dberlin.org (h-69-3-5-6.MCLNVA23.covad.net [69.3.5.6]) by mail.cdt.org (Postfix) with ESMTP id 2DB7B490128; Thu, 12 Dec 2002 00:30:56 -0500 (EST) Received: from [192.168.1.2] (HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0.2) with ESMTP-TLS id 1780208; Thu, 12 Dec 2002 00:33:20 -0500 Date: Wed, 11 Dec 2002 22:18:00 -0000 From: Daniel Berlin To: "Sanjiv Kumar Gupta, Noida" Cc: Dale Johannesen , "" Subject: RE: possible gcse failure: not able to eliminate redundant loads In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-12/txt/msg00621.txt.bz2 On Thu, 12 Dec 2002, Sanjiv Kumar Gupta, Noida wrote: > > > >> But surely it should be smart enough to know they don't alias? > >It depends on what it looks like at the RTL level. > the references of a[4] and a[1] appear as two pointer pseudos > which gcc can not determine that they have been computed with distinct > offsets from same base. Thus assumes aliasing. > I am implementing mod-k residue technique in GCC > (described in "alias analysis of executable code", Debray98 et. al) > to fix this. > >> This is still a bug, possibly an important one for performance. > > >Store motion can't handle this right now. > >It was built to handle a certain special case. > >Improve it so it does more. > >It's not broken, just not as good as it could be. > > Store motion is currently disabled. see gcse.c line 910 Err, you don't know this, but you don't need to tell me. I know more about the history of store motion than i would ever care to know. :) > > /* Store motion disabled until it is fixed. */ > if (0 && !optimize_size && flag_gcse_sm) > store_motion (); > > I don't know what's stopping this? I will try to find > related PRs and have a look into them. What's stopping is twofold. 1. in current form, it takes a not insignificant amount of time, and does nothing (If you look at the mailing list archives, you'll note i collected stats, and found it applied <10 times in the bootstrap). 2. There is code where it does apply, and does the wrong thing. Both are bad. Feel free to reenable it and watch it do nothing for most stores. Now i remember what case it handles: It will only move stores to globals right now, and even then, only in special cases. Check find_moveable_store. :) > > --Sanjiv >