From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29601 invoked by alias); 14 May 2003 16:16:43 -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 29555 invoked from network); 14 May 2003 16:16:42 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 14 May 2003 16:16:42 -0000 Received: from localhost.localdomain (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 3F0D8800021; Wed, 14 May 2003 12:16:40 -0400 (EDT) Subject: Re: [tree-ssa] RFC: Dropping INDIRECT_REF variables From: Andrew MacLeod To: Diego Novillo Cc: gcc mailing list In-Reply-To: <20030514150917.GA12344@tornado.toronto.redhat.com> References: <20030514150917.GA12344@tornado.toronto.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 14 May 2003 16:16:00 -0000 Message-Id: <1052929000.3373.360.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-05/txt/msg01416.txt.bz2 On Wed, 2003-05-14 at 11:09, Diego Novillo wrote: > - The SSA->normal pass may also need to handle INDIRECT_REF > variables with care. Since an INDIRECT_REF variable has two > SSA versions in it, overlapping live ranges of the base pointer > or the INDIRECT_REF node may need extra supporting code (this > is just a vague concern, Andrew?). > The SSA->Normal pass is in the process of ignoring INDIRECT_REF variables anyway, but it does have to handle them when they occur as real operands.. ie T.14 = (*p_5)_8 needs to be recognized by the SSA->normal translator, and converted to T.14 = *p_5 So it requires a bunch of special casing during building, analyzing/ and translation out. Having them go away or at least never be a part of a real operands is the way to go. > - We disable the ability to treat non-aliased pointer > dereferences as if they were variables. We would lose the > ability to do some optimizations like: > > foo () foo () > { { > char[7] * T.1; char[7] * T.1; > char T.2; char T.2; > char * s; char * s; > > T.1 = "string"; | return (int)100; > s = (char *)T.1; < > *s = 100; < > T.2 = *s; < > return (int)T.2; < > } } > > I can live with this loss. I cannot say for sure if this is > going to be a real problem because I still haven't implemented > the change. If it turns out to be a huge loss, then we should > either reconsider or think of alternatives. > All you were doing were taking unaliased dereferences, and replacing them with a variable. It was basically a simple expression replacement based on a single simple case... a dereference of a memory location that wasn't alasied with anything. I find it hard to beleive that this isn't going to be caught by some other optimization that handles expressions and looks at loads and stores. Andrew