From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13017 invoked by alias); 15 May 2003 18:01:52 -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 12920 invoked from network); 15 May 2003 18:01:50 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 15 May 2003 18:01:50 -0000 Received: from [192.168.1.3] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b6) with ESMTP-TLS id 3962615; Thu, 15 May 2003 14:01:50 -0400 Date: Thu, 15 May 2003 18:01:00 -0000 Subject: Re: [tree-ssa] copy propagation and the abstraction penalty Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Diego Novillo , "gcc@gcc.gnu.org" To: Joe Buck From: Daniel Berlin In-Reply-To: <20030515100914.B17159@synopsys.com> Message-Id: <4C8FA7F1-86FF-11D7-953A-000A95A34564@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01537.txt.bz2 On Thursday, May 15, 2003, at 01:09 PM, Joe Buck wrote: > On Thu, May 15, 2003 at 10:10:22AM -0400, Diego Novillo wrote: > >> There's a few bits still missing, but we should be getting there. In >> this particular testcase I see: >> >> * Structures. We only build enough SSA links to prove liveness. >> Two alternatives to dealing with this is using ESSA from the >> SSAPRE engine and/or rely on a scalarization pass. > > Since this is the absolutely most common defect in our current C++ > compiler, it seems worth trying to tune optimization to solve it > directly, > rather than trying to solve a harder, more general problem. > > If copy propagation can store the content of individual structure > fields, > then it seems that you don't need the rest of scalarization But the amount of memory necessary to do SSA on component_refs gets *really* large unless you share the component_refs for the SSA variables where possible. Diego and I went through this back when we had Factored Use-Def chains. I really think we *should* have structure accesses renamed, and it's easier than doing pointer renaming (since unions are the only thing you have to really worry about, and you can calculate the offsets). It's just something that we had punted on until later (after the great FUD chain -> renaming switchover). I guess now = later. --Dan