From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 911 invoked by alias); 20 Oct 2004 17:53:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 903 invoked from network); 20 Oct 2004 17:53:16 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 20 Oct 2004 17:53:16 -0000 Received: from [129.34.20.23] (HELO [9.2.217.169]) by dberlin.org (CommuniGate Pro SMTP 4.2.1) with ESMTP id 7401540; Wed, 20 Oct 2004 13:53:16 -0400 In-Reply-To: <1098293613.22552.36.camel@localhost.localdomain> References: <1098293613.22552.36.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "gcc-patches@gcc.gnu.org" , Andrew Macleod From: Daniel Berlin Subject: Re: [PATCH]: Implement must-def kill operand Date: Wed, 20 Oct 2004 17:56:00 -0000 To: Diego Novillo X-SW-Source: 2004-10/txt/msg01750.txt.bz2 On Oct 20, 2004, at 1:33 PM, Diego Novillo wrote: > On Sun, 2004-10-17 at 22:00, Daniel Berlin wrote: > >> This is a revision of the previous patch, the main change is that it >> no >> longer requires DCE to go into and out of SSA to rename the virtual >> must-def operands, as Andrew requested. The renaming it does >> in DCE is just the 3rd phase of the regular renamer (rewriting >> reaching >> definitions), >> > I would rather parameterize the renamer to deal with this situation. > Just to make sure I understood the problem and the IRC discussion. > Here > we have the following situation: > > # A_4 = V_MUST_DEF > 1. A = ...; > > # A_5 = V_MUST_DEF > 2. A = ...; > > A_4 is dead because no statement uses A_4 (the RHS of a V_MUST_DEF is > not a use, it only specifies which version is this V_MUST_DEF killing). > Once we remove statement (1), we need to tell statement (2) that it no > longer kills A_4, it now kills whichever version was left dominating it > (it may or may not be A_3). > Right. > What we need here is a regular renaming pass, but not all of it. We > only need to (a) detect def sites, (b) walk the dominator the dominator > tree rewriting the operands of V_MUST_DEFs with CURRENT_DEF. That is, > we need to skip the PHI insertion phase. Okay. > > So, I guess this involves a new TODO_* flag (TODO_fix_def_def_chains?) > which does (a) and (b) using the existing renamer. The additional > logic > in the renamer should not slow it down one bit, nor make it more > complicated to follow. I'll implement this and repost the patch. I assume nobody really had much problem with the *other* parts of the patch? > Diego. >