From patchwork Fri Jun 22 00:58:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 166456 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 43476B6FA1 for ; Fri, 22 Jun 2012 11:11:48 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1340932308; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=m8cZfSVX1c6vVzsYJXsD g3G+hmA=; b=VmV2Zw0Rjte9zrHgbE7ivtzqK7FDF56co/vTASDF7NcDCFpaa+5p RERQvF4nxN+1cD1IgBEC4WxmO7lxjEzsS40CPobQAOp+DvWBSFMekK9Qh3PLOxOf 2yErv7wlT0oaQMyB9bl3vpW5hoEyTzDl3UtLWPN9IY3hcUOqOsZELnw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=oOpizM4VMq7HbmA7Zvg6CdhqmVS11i66lfXCHhuM7fAmTGST+9Ymm80qXL3DCE fKbGXWF5KSHTxdSLzmFTkIgz18uLPc53prvJTatAUlzKpsfGazs9/+XWzS/Y8nxs 4WYKZY5deWtLp3eUVuKw0A480FBxBskcmlUNbCRpZs/9A=; Received: (qmail 20735 invoked by alias); 22 Jun 2012 01:11:37 -0000 Received: (qmail 20716 invoked by uid 22791); 22 Jun 2012 01:11:34 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS 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; Fri, 22 Jun 2012 01:11:19 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5M1BIAX022207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jun 2012 21:11:18 -0400 Received: from freie.oliva.athome.lsd.ic.unicamp.br (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5M1BFVK001877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 21:11:18 -0400 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie (8.14.5/8.14.5) with ESMTP id q5M0whm7018922; Thu, 21 Jun 2012 21:58:43 -0300 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q5M0wg9h028312; Thu, 21 Jun 2012 21:58:42 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id q5M0wfvG028310; Thu, 21 Jun 2012 21:58:41 -0300 From: Alexandre Oliva To: Richard Guenther Cc: "H.J. Lu" , Richard Henderson , Jakub Jelinek , gcc-patches@gcc.gnu.org Subject: Re: [PR49888, VTA] don't keep VALUEs bound to modified MEMs References: <20120523101349.GN16117@tyan-ft48-01.lab.bos.redhat.com> <4FD7A9BE.4080405@redhat.com> Date: Thu, 21 Jun 2012 21:58:41 -0300 In-Reply-To: (Richard Guenther's message of "Wed, 20 Jun 2012 11:00:15 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Jun 20, 2012, Richard Guenther wrote: > I have a question on the pre-existing condition > - if (GET_CODE (y) == AND || ysize < -INTVAL (XEXP (x, 1))) > xsize = -1; > so if this condition is not true then we simply strip off the AND of X and > do not adjust xsize at all? Likewise we do not adjust c? How can that > be conservatively correct? Yeah, xsize = -1 makes x “infinitely large”, so it will overlap if the RTXs are in any way related, or something like that. > Thus, I'd rather see > if (GET_CODE (x) == AND && CONST_INT_P (XEXP (x, 1))) > { > + HOST_WIDE_INT sc = INTVAL (XEXP (x, 1)); > + unsigned HOST_WIDE_INT uc = sc; > + if (xsize > 0 && sc < 0 && -uc == (uc & -uc)) > + { > + xsize -= sc + 1; > + c -= sc; > return memrefs_conflict_p (xsize, canon_rtx (XEXP (x, 0)), > ysize, y, c); > } > } > as the sole supported case. Ack. Regstrapped successfully, checking this in. for gcc/ChangeLog from Alexandre Oliva PR debug/53671 PR debug/49888 * alias.c (memrefs_conflict_p): Improve handling of AND for alignment. Index: gcc/alias.c =================================================================== --- gcc/alias.c.orig 2012-06-21 15:05:48.144424495 -0300 +++ gcc/alias.c 2012-06-21 15:21:56.000000000 -0300 @@ -2097,25 +2097,32 @@ memrefs_conflict_p (int xsize, rtx x, in break; } - /* Treat an access through an AND (e.g. a subword access on an Alpha) - as an access with indeterminate size. Assume that references - besides AND are aligned, so if the size of the other reference is - at least as large as the alignment, assume no other overlap. */ + /* Deal with alignment ANDs by adjusting offset and size so as to + cover the maximum range, without taking any previously known + alignment into account. */ if (GET_CODE (x) == AND && CONST_INT_P (XEXP (x, 1))) { - if (GET_CODE (y) == AND || ysize < -INTVAL (XEXP (x, 1))) - xsize = -1; - return memrefs_conflict_p (xsize, canon_rtx (XEXP (x, 0)), ysize, y, c); + HOST_WIDE_INT sc = INTVAL (XEXP (x, 1)); + unsigned HOST_WIDE_INT uc = sc; + if (xsize > 0 && sc < 0 && -uc == (uc & -uc)) + { + xsize -= sc + 1; + c -= sc; + return memrefs_conflict_p (xsize, canon_rtx (XEXP (x, 0)), + ysize, y, c); + } } if (GET_CODE (y) == AND && CONST_INT_P (XEXP (y, 1))) { - /* ??? If we are indexing far enough into the array/structure, we - may yet be able to determine that we can not overlap. But we - also need to that we are far enough from the end not to overlap - a following reference, so we do nothing with that for now. */ - if (GET_CODE (x) == AND || xsize < -INTVAL (XEXP (y, 1))) - ysize = -1; - return memrefs_conflict_p (xsize, x, ysize, canon_rtx (XEXP (y, 0)), c); + HOST_WIDE_INT sc = INTVAL (XEXP (y, 1)); + unsigned HOST_WIDE_INT uc = sc; + if (ysize > 0 && sc < 0 && -uc == (uc & -uc)) + { + ysize -= sc + 1; + c += sc; + return memrefs_conflict_p (xsize, x, + ysize, canon_rtx (XEXP (y, 0)), c); + } } if (CONSTANT_P (x))