From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18124 invoked by alias); 3 Mar 2008 19:42:22 -0000 Received: (qmail 18116 invoked by uid 22791); 3 Mar 2008 19:42:21 -0000 X-Spam-Check-By: sourceware.org Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Mar 2008 19:41:52 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m23JhmgA007576 for ; Mon, 3 Mar 2008 14:43:48 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m23Jfnuk220950 for ; Mon, 3 Mar 2008 14:41:49 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m23Jfne2020923 for ; Mon, 3 Mar 2008 14:41:49 -0500 Received: from [9.10.86.186] (otta.rchland.ibm.com [9.10.86.186]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m23Jfngp020890; Mon, 3 Mar 2008 14:41:49 -0500 Subject: Re: [PATCH] PR35371 GCSE loses track of REG_POINTER attribute From: Peter Bergner To: Jeff Law Cc: Richard Sandiford , gcc-patches , "H.J. Lu" In-Reply-To: <47CC4E4D.5040706@redhat.com> References: <20080225222624.GA26857@vervain.rchland.ibm.com> <87skzfzkvh.fsf@firetop.home> <1204052325.7014.2.camel@otta> <47C467BA.1090308@redhat.com> <1204240130.7376.16.camel@otta> <47CC4E4D.5040706@redhat.com> Content-Type: text/plain Date: Mon, 03 Mar 2008 19:42:00 -0000 Message-Id: <1204573308.6969.8.camel@otta> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00159.txt.bz2 On Mon, 2008-03-03 at 12:15 -0700, Jeff Law wrote: > > Do you mean fix it up and then call it from more than just CSE? > > Currently, the only call to reg_scan() isn't in a location that > > will help me. > No. I mean make it smarter. If you read the code it's amazingly > simplistic and punts propagation of REG_POINTER for any pseudo > that is set more than once. > > It shouldn't be terribly difficult to build a simple propagation > engine that handles multiple sets. Sorry, making it "smarter" is what I meant by "fix it up". My problem with it, as I mentioned in my previous note, is that the only location it is currently called doesn't help me. I guess what I was asking was there shouldn't be a problem with me calling it from another location, correct? H.J., Did you see my request to test the patch attached to: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01442.html to verify I haven't changed x86/x86_64's SPEC scores due to the rtlanal.c change? Peter