From patchwork Sat Nov 17 10:28:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 199825 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 E39C52C0092 for ; Sat, 17 Nov 2012 21:29:16 +1100 (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=1353752957; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=SoCkxq4a8icubn/0NLrgwdcmDf8=; b=bOroO3Hng1Ju1uy +HE+ccbcINYiDgTt2/4+t8y2IUKbWNm9Qmol9u/FQbkAXJME4FxmjbeeLqIduowj uoDR831lL/PZPg+voxKvFmDQmmVJC3/XHDYYGJUZN6xLoVuI1eC3uLhsi4djTdcz acavunV63IsApepL1TpWaopl4ngc= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=mdak/MAO18GI5ltq9GYwGOtbjB/1bp2BPWp2VpriPX8xJ7g2BiIH+cxXBM94Ue QXC5A2b6K0wQ+bZmxkgqcUr7lmLu81+RTxmn4ZECCpRKjBKV+uPs82AArkNTM6aF brEDvfl0b71I74ldLrv1xvjjUIBvnifrml895bCR3gwmM=; Received: (qmail 14142 invoked by alias); 17 Nov 2012 10:29:11 -0000 Received: (qmail 14130 invoked by uid 22791); 17 Nov 2012 10:29:10 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Nov 2012 10:29:05 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TZfe4-0006Vq-0w from Tom_deVries@mentor.com ; Sat, 17 Nov 2012 02:29:04 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Nov 2012 02:29:03 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Sat, 17 Nov 2012 10:29:02 +0000 Message-ID: <50A766EA.7000507@mentor.com> Date: Sat, 17 Nov 2012 11:28:58 +0100 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Richard Sandiford CC: "gcc-patches@gcc.gnu.org" Subject: [PATCH, PR55315] Don't assume a nonzero address plus a const is a nonzero address 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 Richard, This patch fixes PR 55315. When compiling for the mips target with -O2, function f is folded to 0, while the address of data is not known compile-time: ... int data[4096]; int f (void) { return (((unsigned int) &data[0]) == 0xdeadbea0U); } .... What happens is that expand turns the comparison into the equivalent of: ... (((unsigned int) &data[0]) + (~0xdeadbea0U + 1)) == 0 ... and then nonzero_address_p triggers here during cse: ... case PLUS: if (CONST_INT_P (XEXP (x, 1))) return nonzero_address_p (XEXP (x, 0)); ... and '(((unsigned int) &data[0]) + (~0xdeadbea0U + 1))' is considered a nonzero address, and the comparison evaluates to 0. This example is related to PR 29519, in fact you mention the code pattern expand generates in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519#c5. But the patch for that PR does not address this example. This patch prevents nonzero_address_p from assuming that a nonzero address plus a const is a nonzero address. Build and reg-tested on mips. OK for trunk? Thanks, - Tom 2012-11-17 Tom de Vries PR rtl-optimization/55315 * rtlanal.c (nonzero_address_p): Don't assume a nonzero address plus a const is a nonzero address. * gcc.target/mips/pr55315.c: New test. Index: gcc/rtlanal.c =================================================================== --- gcc/rtlanal.c (revision 193478) +++ gcc/rtlanal.c (working copy) @@ -392,10 +392,8 @@ nonzero_address_p (const_rtx x) return nonzero_address_p (XEXP (x, 0)); case PLUS: - if (CONST_INT_P (XEXP (x, 1))) - return nonzero_address_p (XEXP (x, 0)); /* Handle PIC references. */ - else if (XEXP (x, 0) == pic_offset_table_rtx + if (XEXP (x, 0) == pic_offset_table_rtx && CONSTANT_P (XEXP (x, 1))) return true; return false; Index: gcc/testsuite/gcc.target/mips/pr55315.c =================================================================== --- /dev/null (new file) +++ gcc/testsuite/gcc.target/mips/pr55315.c (revision 0) @@ -0,0 +1,11 @@ +/* { dg-do compile } */ + +int data[4096]; + +int +f (void) +{ + return (((unsigned int) &data[0]) == 0xdeadbea0U); +} + +/* { dg-final { scan-assembler-not "\tmove\t\\\$2,\\\$0" } } */