From patchwork Mon Sep 26 13:55:55 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 675176 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sjQVX12hRz9s5g for ; Mon, 26 Sep 2016 23:56:19 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=fRjLEilq; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; q=dns; s= default; b=RZ/XcIkuOdOgdzv+EgbH5ySBT78TIYdpdoU6mF9IrRME3hvxWSqpg pDiNu7qkoPoYlW18LMLNonZDI7poUt71/1bKP0JR2ST2uj2+Fa6tlswTyk2T5XTW 2xCNs0AkF/1+yyQItGEgeXt2lfyjHhBHMb6EMVVbIJBWSVNjrbJmng= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; s= default; bh=HiCwk1McIUzeIN7qGFf4E4df5mg=; b=fRjLEilqV7Rb6xQKq8mz 3gxEuGcrZCg2lq+9NYeJoZRVk10s34Rqhu4MUAZ3vPLCiTEs19tyo36leU2I3ty7 tGyO5sDKXiPd7EQYEXBCpkUvyJOMHUbGCwlgF0fMXJgz3AIapSKqbYhKJPXymP+e zCwxuiXyggbzT00++hycv4k= Received: (qmail 89662 invoked by alias); 26 Sep 2016 13:56:10 -0000 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 Received: (qmail 89632 invoked by uid 89); 26 Sep 2016 13:56:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=reg-tested, Hx-languages-length:1433, choses, H*MI:eurprd07 X-HELO: COL004-OMC3S3.hotmail.com Received: from col004-omc3s3.hotmail.com (HELO COL004-OMC3S3.hotmail.com) (65.55.34.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Sep 2016 13:55:59 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com ([65.55.34.137]) by COL004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 26 Sep 2016 06:55:58 -0700 Received: from AM5EUR02FT025.eop-EUR02.prod.protection.outlook.com (10.152.8.56) by AM5EUR02HT060.eop-EUR02.prod.protection.outlook.com (10.152.9.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Mon, 26 Sep 2016 13:55:56 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.8.59) by AM5EUR02FT025.mail.protection.outlook.com (10.152.8.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Mon, 26 Sep 2016 13:55:56 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0639.011; Mon, 26 Sep 2016 13:55:55 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Vladimir Makarov , Jeff Law Subject: [PATCH, LRA] Fix PR 77714 Date: Mon, 26 Sep 2016 13:55:55 +0000 Message-ID: authentication-results: spf=softfail (sender IP is 10.152.8.59) smtp.mailfrom=hotmail.de; gcc.gnu.org; dkim=none (message not signed) header.d=none; gcc.gnu.org; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 10.152.8.59 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; AM5EUR02HT060; 6:R8oKLqMLQKFV/6cHBsR+kDLR6Uh/S8yJz/aRcChJT+fkP1bwt+SkPpxRjOD2IcqApAiGSv39WBRGAOKshnjiv7C/rk/Mh+omBw3Yn/DmiQag2ML790Tb6iaFoBLGQK1jTEQTe/oznOv57MDj1M0ExhoKGxXJHS1gmp5CbOLDlhoP2Cq8DWmWdL1r5WKTE6r4Dx34LzFTcw2oURzD69BQMlbvN9VMDpUaKrWBTy45RclSiEWji60srATzdyOO6mt/IWPfYD/1AMqxongH5Py9OYM3NIpd0xHMxX34oU7fnf4=; 5:mOSNg3kin1zz4lkPsY2MZZo8qZJIEvW250k3XX8/iiKN7/LwcAQSeOiPFBAiyjj5lpI0Qaw3a0UTccsCg3nv1bR6NAVJ7f/9XZyAiSkJeel4x8DJsP0pZPXMn81hLgxBbUHkxyovp50MmIkMVyop+g==; 24:lqO06gYJemGJgwJfWH4EvHBlQTPjbP37QqpfksDckrAoksc89axd5i/46kl2hatigShG2ybpCvQD0n26BtVdQhcnaL3vTMrOsDlZVCAczwU=; 7:7mdoQv3xV/xyOaltuAokowmbtVOoQSYcZqodjyQZDAKtuawX6BU9CctGieEQQ8QABcUG4sa1b7MFdNXLfEtfLzZyDVuTu7yo/emewehaJWLp0GhrDrPPRT73cLDUjHrKVLV3LBgJELHIB9fOOkoG0krjd14Xh8KviOUuLeLigxDHthcAyvh09OHy0jJznm9Cb49zGdvZWqHbU5GWuKQBbJq/hEG+qLN+NVhr6PUP0yb9ScFO11/6t9JksBnsG3JsmezLUdT34LAFskrgXmZlmDjmFhX/cX/A6jsBV09+7k9UGXwf+GASL5e9DycQifIK x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5EUR02HT060; H:AM4PR0701MB2162.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 2021c20a-e9ac-4ee1-e889-08d3e614d55f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:AM5EUR02HT060; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(102415321)(82015046); SRVR:AM5EUR02HT060; BCL:0; PCL:0; RULEID:; SRVR:AM5EUR02HT060; x-forefront-prvs: 00770C4423 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 13:55:55.6500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT060 Hi! This fixes another fallout of the recent change in the pattern matching, which makes LRA choose a different alternative for this insn: (insn 48 21 23 3 (set (reg/f:SI 102 sfp) (reg/f:SI 7 r7)) 808 {*thumb1_movsi_insn} (nil)) This is replaced as a special case to set((sfp)(r7-sfp_fp_elim_off)). LRA choses thumb1_addsi3, alt 2 instead of alt 1, because sfp != r7, while elimination of sfp->r7. Unfortunately the insn gets a REG_EQUAL note temporarily attached, which is spoiled by the elimination, so the reg-note is no longer usable, and the instruction gets deleted in the final transformation. So, as it looks like, this was a latent bug, as it is not OK to have an alias on any RTX, except on a simple REG. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. 2016-09-26 Bernd Edlinger PR rlt-optimization/77714 * lra-eliminations.c (eliminate_regs_in_insn): Avoid alias on REG_EQUAL note. Index: gcc/lra-eliminations.c =================================================================== --- gcc/lra-eliminations.c (revision 240471) +++ gcc/lra-eliminations.c (working copy) @@ -981,7 +981,7 @@ eliminate_regs_in_insn (rtx_insn *insn, bool repla } lra_update_insn_recog_data (insn); /* Add offset note for future updates. */ - add_reg_note (insn, REG_EQUAL, src); + add_reg_note (insn, REG_EQUAL, copy_rtx (src)); return; } }