From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30493 invoked by alias); 27 Nov 2008 13:48:31 -0000 Received: (qmail 30472 invoked by uid 22791); 27 Nov 2008 13:48:30 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.168) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Nov 2008 13:47:55 +0000 Received: by ug-out-1314.google.com with SMTP id q7so1832132uge.10 for ; Thu, 27 Nov 2008 05:47:52 -0800 (PST) Received: by 10.103.222.1 with SMTP id z1mr2646364muq.100.1227793672491; Thu, 27 Nov 2008 05:47:52 -0800 (PST) Received: by 10.103.248.15 with HTTP; Thu, 27 Nov 2008 05:47:52 -0800 (PST) Message-ID: <84fc9c000811270547w126cf34paf748488bd9428b7@mail.gmail.com> Date: Thu, 27 Nov 2008 15:46:00 -0000 From: "Richard Guenther" To: luisgpm@linux.vnet.ibm.com Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX Cc: "Jeff Law" , "David Edelsohn" , "Andrew Pinski" , sje@cup.hp.com, "Richard Henderson" , "Peter Bergner" , gcc-patches@gcc.gnu.org, paolo.carlini@oracle.com In-Reply-To: <1227792133.20350.3.camel@gargoyle> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <303e1d290811061151l43701067pcfb7725fdc73f31c@mail.gmail.com> <4913621E.90508@redhat.com> <303e1d290811061452g1dae05efg7e6e52a112c32f5f@mail.gmail.com> <49137ABC.309@redhat.com> <1227792133.20350.3.camel@gargoyle> 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/msg01407.txt.bz2 On Thu, Nov 27, 2008 at 2:22 PM, Luis Machado wrote: > Hi, > > The attached patch changes the handling of LO_SUM in "find_base_term" to > what "find_base_value" does. > > No additional testsuite failures were noticed and SPEC2K numbers are > stable. Vortex 32-bit (that had degraded due to this problem) is back to > normal (up 3%) on PPC. > > OK for mainline? Ok. Thanks, Richard. > Thanks, > 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 >> > > 2008-11-27 Luis Machado > > * alias.c (find_base_term): Synch LO_SUM handling with what > find_base_value does. > > Index: gcc/alias.c > =================================================================== > --- gcc.orig/alias.c 2008-11-25 19:43:01.000000000 -0800 > +++ gcc/alias.c 2008-11-27 04:54:09.000000000 -0800 > @@ -1408,6 +1408,9 @@ > return 0; > /* Fall through. */ > case LO_SUM: > + /* The standard form is (lo_sum reg sym) so look only at the > + second operand. */ > + return find_base_term (XEXP (x, 1)); > case PLUS: > case MINUS: > { > > >