From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21406 invoked by alias); 12 May 2003 15:57:13 -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 20976 invoked from network); 12 May 2003 15:57:08 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 12 May 2003 15:57:08 -0000 Received: from localhost.localdomain (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 3584C800030; Mon, 12 May 2003 11:57:08 -0400 (EDT) Subject: Re: [tree-ssa] Out of SSA status and issues From: Andrew MacLeod To: Diego Novillo Cc: gcc mailing list In-Reply-To: <20030512153811.GA32572@tornado.toronto.redhat.com> References: <1052750563.2730.317.camel@p4> <20030512153811.GA32572@tornado.toronto.redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 12 May 2003 15:57:00 -0000 Message-Id: <1052755028.2743.368.camel@p4> Mime-Version: 1.0 X-SW-Source: 2003-05/txt/msg01148.txt.bz2 On Mon, 2003-05-12 at 11:38, Diego Novillo wrote: > On Mon, May 12, 2003 at 10:42:43AM -0400, Andrew MacLeod wrote: > > > So this problem needs to be resolved before we can turn on overlapping > > ranges. We must not propagate copies which are going to cause conflicts > > with other registers that are used across abnormal critical edges. > > > Perhaps we could just teach copy-prop not to use critical edges > for the time being. Or, to avoid pessimizing too much, we could > try and use the same check we have now for overlapping live > ranges in the SSA renamer. I'm not sure if it's feasible, > though. > Unfortunately, it not propagating over a critical edge thats the problem. Its propagating a copy past another use to form an overlapping live range where both of those values are used in a PHI node at some point across abnormal critical edges. I beleive the bvrute force approach is to flag any variables which are elements of PHI's acroiss an abnormal ciroitcal edge, and never copy propagate them ie, so in the example, when you look at the PHI, you see p_9 and p_14 are used across abnormal critical edges, so you stick them in a list of variables never to copy propagate. I dont know that another optimiation might not do something which results in the same condition or not. Time will tell. On another note, shouldn't the into-ssa-pass's copy propagation only be turned on when -ftree-copyprop is specified? I think we do it all the time right now... thus my problem in libstdc++ even without -ftree-copyprop... > We can't just unshare the INDIRECT_REF nodes. The solution needs > to share all the nodes that have the same pointer (i.e., all the > (*p_3)_n SSA names need to have the same variable *p_3 as their > SSA_NAME_VAR). Once I fix that, it should all just work (FLW). > Thats the working theory anwyay :-) Andrew