From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10302 invoked by alias); 16 Jan 2013 19:54:32 -0000 Received: (qmail 10293 invoked by uid 22791); 16 Jan 2013 19:54:31 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jan 2013 19:54:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0GJsQpn024591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jan 2013 14:54:26 -0500 Received: from anchor.twiddle.home (vpn-224-89.phx2.redhat.com [10.3.224.89]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0GJsPQQ016489; Wed, 16 Jan 2013 14:54:25 -0500 Message-ID: <50F70571.3080606@redhat.com> Date: Wed, 16 Jan 2013 19:54:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexandre Oliva CC: ubizjak@gmail.com, Aldy Hernandez , gcc-patches@gcc.gnu.org Subject: Re: [PR55547] fix alias regression on alpha on misaligned symbols References: <50F582CE.3090201@redhat.com> <50F585DB.2020706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2013-01/txt/msg00879.txt.bz2 On 01/15/2013 08:29 PM, Alexandre Oliva wrote: > if (rtx_equal_for_memref_p (x, y)) > { > - if (xsize <= 0 || ysize <= 0) > + if (xsize == 0 || ysize == 0) > return 1; > - if (c >= 0 && xsize > c) > + if (c >= 0 && abs (xsize) - c > 0) > return 1; > - if (c < 0 && ysize+c > 0) > + if (c < 0 && abs (ysize) + c > 0) > return 1; > return 0; > } > @@ -2063,7 +2063,8 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y, HOST_WIDE_INT c) > y0 = canon_rtx (XEXP (y, 0)); > if (rtx_equal_for_memref_p (x0, y0)) > return (xsize == 0 || ysize == 0 > - || (c >= 0 && xsize > c) || (c < 0 && ysize+c > 0)); > + || (c >= 0 && abs (xsize) - c > 0) > + || (c < 0 && abs (ysize) + c > 0)); > > /* Can't properly adjust our sizes. */ > if (!CONST_INT_P (x1)) > @@ -2119,8 +2120,9 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y, HOST_WIDE_INT c) > if (CONST_INT_P (x) && CONST_INT_P (y)) > { > c += (INTVAL (y) - INTVAL (x)); > - return (xsize <= 0 || ysize <= 0 > - || (c >= 0 && xsize > c) || (c < 0 && ysize+c > 0)); > + return (xsize == 0 || ysize == 0 > + || (c >= 0 && abs (xsize) - c > 0) > + || (c < 0 && abs (ysize) + c > 0)); > } I notice that these expressions (including the first hunk that uses ifs) are now all the same. It would seem extremely prudent to pull this out to a function so that they stay the same. That said, I question the change of <= to == 0. If negative, we don't know how much overlap there is as far as I can see. > > if (GET_CODE (x) == CONST) > @@ -2139,7 +2141,8 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y, HOST_WIDE_INT c) > if (CONSTANT_P (y)) > return (xsize <= 0 || ysize <= 0 > || (rtx_equal_for_memref_p (x, y) > - && ((c >= 0 && xsize > c) || (c < 0 && ysize+c > 0)))); > + && ((c >= 0 && abs (xsize) - c > 0) > + || (c < 0 && abs (ysize) + c > 0)))); This hunk is not needed, as we begin by eliminating <= 0. So the abs is certain to do nothing. r~