From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5078 invoked by alias); 15 Mar 2004 16:42:19 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 5047 invoked from network); 15 Mar 2004 16:42:18 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 15 Mar 2004 16:42:18 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i2FGGZx03618; Mon, 15 Mar 2004 11:16:35 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2FGgFM28417; Mon, 15 Mar 2004 11:42:15 -0500 Received: from p4 (vpn50-2.rdu.redhat.com [172.16.50.2]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i2FGgDR03522; Mon, 15 Mar 2004 08:42:13 -0800 Subject: Re: Bug 14562 : copyrename & PRE From: Andrew MacLeod To: Daniel Berlin Cc: Jeff Law , Richard Henderson , gcc-bugs In-Reply-To: References: <1079365012.4007.3467.camel@p4> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 15 Mar 2004 16:42:00 -0000 Message-Id: <1079368934.4011.3551.camel@p4> Mime-Version: 1.0 X-SW-Source: 2004-03/txt/msg01834.txt.bz2 List-Id: On Mon, 2004-03-15 at 11:17, Daniel Berlin wrote: > On Mar 15, 2004, at 10:36 AM, Andrew MacLeod wrote: > Because PARM_DECL's don't have a bb_for_stmt(SSA_NAME_DEF_STMT > (PARM_DECL)), we special case them in PRE when it comes to seeing if > they are actually undefined or not. > > In reality, they should have a bb_for_stmt (SSA_NAME_DEF_STMT > (parm_decl)) of ENTRY_BLOCK_PTR for those live on entry, and proper > bb_for_stmt (SSA_NAME_DEF_STMT (parm_decl)) for others. > > People seemed to agree with this (Richard and Jeff, IIRC), i just never > got around to it. > Yes, I agree it ought to be this way. > The code in question that treats PARM_DECL special is: > > > /* This guards against moving around undefined variables. > However, PARM_DECL is special because it *IS* live on entry, > so it's not really undefined. */ > if (!defbb && TREE_CODE (SSA_NAME_VAR (use)) != PARM_DECL) > return true; > else if (!defbb && TREE_CODE (SSA_NAME_VAR (use)) == PARM_DECL) > return false; > if (dominated_by_p (CDI_DOMINATORS, bb, defbb)) > return false; > > > Does copyrename make this no longer true somehow? Did you ever make adjustments when default_def() was introduced? We have a situation here where some versions of 'k' have default_dfef() set because they are the incoming default value, and are live on entry. Copy rename has in this case added a new defintion of 'k', k_29, which although the base variable is a PARM, it does have a defined block. > If so, we probably should just make the bb_for_stmt (SSA_NAME_DEF_STMT > (PARM_DECL)) be ENTRY_BLOCK_PTR when it is approriate, and stop special > casing them, which is probably causing this bug. > Maybe... I dont think thats this problem. But maybe it is :-) > This is the only place we special case PARM_DECL in all of PRE. > Well, dont you try to reconstruct expressions based on the base variable or something at some point? We have a case where we have a PARM_DECL 'k', and there are 2 PHI nodes in one block for K # k_1 = PHI _29(0), k_41(1)>; # k_26 = PHI _2(0), k_39(1)>; and PRE makes one of them go away... Maybe you ought to take a quick look at the test case, its not a very big one, and you understand PRE far better than I. The only transformation difference that matters (I think :-), is that copyrename has renamed T.1_29 to be k_29. It changed the base variable for version 29 to 'k'. And PRE decided it should do something to it, and appears to do something wrong. It probably wouldn't take long for you to see what wrong. Either its something I did about PARM_DECLs, or an assumption PRE is making, Im not sure which. Maybe pre has done things OK, and someone later is screwing it up, but that fact the PRE looks at this expression now, and it didnt before makes me suspicious :-) Thanks Andrew