From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23833 invoked by alias); 7 Nov 2008 18:45:17 -0000 Received: (qmail 23518 invoked by uid 22791); 7 Nov 2008 18:45:16 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Nov 2008 18:44:29 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw2.br.ibm.com (Postfix) with ESMTP id 4672E17F68F for ; Fri, 7 Nov 2008 16:42:52 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mA7Ii3ZQ3371196 for ; Fri, 7 Nov 2008 15:44:03 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mA7IiOYH032276 for ; Fri, 7 Nov 2008 16:44:24 -0200 Received: from [9.8.15.68] ([9.8.15.68]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mA7IiLuj032168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2008 16:44:23 -0200 Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Jeff Law Cc: David Edelsohn , Andrew Pinski , sje@cup.hp.com, Richard Henderson , Peter Bergner , gcc-patches@gcc.gnu.org, paolo.carlini@oracle.com In-Reply-To: <49137ABC.309@redhat.com> References: <303e1d290811061151l43701067pcfb7725fdc73f31c@mail.gmail.com> <4913621E.90508@redhat.com> <303e1d290811061452g1dae05efg7e6e52a112c32f5f@mail.gmail.com> <49137ABC.309@redhat.com> Content-Type: text/plain Date: Fri, 07 Nov 2008 18:58:00 -0000 Message-Id: <1226083462.4507.45.camel@gargoyle> 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-11/txt/msg00299.txt.bz2 Hi, Both approaches fix the regression on vortex with no noticeable performance degradations on 32-bit. I'll check the numbers for 64-bit to make sure we're OK there as well. I'll also check the testsuite results with both approaches. Regards, Luis On Thu, 2008-11-06 at 16:16 -0700, Jeff Law wrote: > David Edelsohn wrote: > > > > > >>> find_base_term() either could check for non-zero base before returning > >>> in the lo_sum/plus/minus case statement or could handle lo_sum > >>> explicitly, like find_base_value(). > >>> > >> I think my suggestion will accomplish the same thing -- and it makes logical > >> sense too -- if we can't determine something from the pointer reg, then we > >> look at other info, such as the symbol_ref within a lo_sum. > >> > > > > Yes, it will accomplish the same thing for this particular case. > > > > Currently find_base_value and find_base_term differ in their handling > > of LO_SUM. My question is whether this fix should maintain the difference > > in algorithms. > I suspect the differences are unintentional and one could easily argue > that find_base_value's handling of LO_SUM is better since LO_SUM has > pretty well defined semantics. One could also argue that both functions > shouldn't be so eager to return the results of the recursive call when > the recursive call returns NULL. > > > Also, RTL alias analysis is very fragile and your suggestion > > may produce more accurate information in other situations, which could > > expose other latent bugs or unexpected behavior. > > > Part of the intent was to get the more accurate info in the presence of > registers marked with REG_POINTER. While it could expose latent bugs, I > think it's the right thing to do -- though we might look for a change > with a smaller impact for the upcoming release since I think we're in > stage3. > > jeff >