From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2108 invoked by alias); 16 Nov 2001 23:02:42 -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 2068 invoked from network); 16 Nov 2001 23:02:38 -0000 Received: from unknown (HELO gremlin.ics.uci.edu) (128.195.1.70) by sourceware.cygnus.com with SMTP; 16 Nov 2001 23:02:38 -0000 Received: from vino.ics.uci.edu ( vino.ics.uci.edu [128.195.11.198] ) by gremlin-relay.ics.uci.edu id aa24113 ; 16 Nov 2001 15:02 PST To: Richard Kenner Cc: gcc@gcc.gnu.org Subject: Re: should MEM tracking be able to optimize this? References: <10111162059.AA25024@vlsi1.ultra.nyu.edu> From: Dan Nicolaescu In-Reply-To: <10111162059.AA25024@vlsi1.ultra.nyu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Nov 2001 05:47:00 -0000 Message-ID: <200111161502.aa24113@gremlin-relay.ics.uci.edu> X-SW-Source: 2001-11/txt/msg00252.txt.bz2 Richard Kenner writes: "calc1" one has too many loads and stores... Should MEM tracking be able to dissambiguate the non-dependend loads and stores in "calc1"? No, only in calc2. The point is that it can now disambiguate when you have separate variables, like you do in calc2. In calc1, what you have are different *fields* of the same variable and that isn't what is tracked. Do you have any plans to do anything about tracking the fields too? Or it's not considered to be worth the effort?