From patchwork Mon Aug 5 20:37:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 1142459 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-506262-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="mWdJFX6/"; dkim-atps=neutral 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 462V2J6jzYz9s3Z for ; Tue, 6 Aug 2019 06:37:44 +1000 (AEST) 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:cc:subject:date:message-id:content-type:mime-version; q=dns; s=default; b=mkzRDPYEwPdnv/qX0cEMDFxzeZ6Pim5BPO14Ef1xL91eNTF1zZ mCT7V/cZd+SnqEnuXzP+0L+LOq28864C9gjFGTnN67fmfgwOmWMB6oSKi4VZbyJ3 8KZ2+4uFnoa6guGvrfzYhLhaK/WyTuu+NhTtiQURmdjCqbbzYP9Jg21V0= 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:cc:subject:date:message-id:content-type:mime-version; s= default; bh=jDTmtarIo7VfDTyCnFcny7nDiok=; b=mWdJFX6/eilINI5jVZrk WPQUE4v40vLmN+mwtcLYvMXa2omKNitdFu1kR439v5pnedaqyh0tyu0Ggu3T1sIj iU7TL1sKyGFoME6VhLPgUB4D3gyj+2cVR4RqL5SSTQxH9PYVSLNEKGwx9AXEQmHY LAaKr2vm5SndQseiQ6BYG8k= Received: (qmail 13260 invoked by alias); 5 Aug 2019 20:37:37 -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 13251 invoked by uid 89); 5 Aug 2019 20:37:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:OUTLOOK, H*MI:PROD, H*c:HHH X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092070014.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.92.70.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Aug 2019 20:37:35 +0000 Received: from AM5EUR03FT003.eop-EUR03.prod.protection.outlook.com (10.152.16.57) by AM5EUR03HT047.eop-EUR03.prod.protection.outlook.com (10.152.17.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18; Mon, 5 Aug 2019 20:37:27 +0000 Received: from VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM (10.152.16.58) by AM5EUR03FT003.mail.protection.outlook.com (10.152.16.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Mon, 5 Aug 2019 20:37:27 +0000 Received: from VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM ([fe80::cd4d:f59f:981a:54d6]) by VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM ([fe80::cd4d:f59f:981a:54d6%5]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 20:37:27 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" CC: Vladimir Makarov Subject: [PATCH] [LRA] Fix wrong-code PR 91109 Date: Mon, 5 Aug 2019 20:37:27 +0000 Message-ID: x-microsoft-original-message-id: <590f0ba7-8a14-233c-792a-c982937ebc79@hotmail.de> MIME-Version: 1.0 Hi! PR 91109 is a wrong-code bug, where LRA is using a scratch register which is actually not available for use, and thus gets clobbered when it should not. That seems to be mostly because the live range info of the cloned schatch register is not working the way how update_scrach_ops sets up the new register. Moreover for the new register there is a much better alternative free register available, so that just not trying the re-use the previous hard register assignment solves the problem. For more background please see the bugzilla PR 91109. Since I am able to reproduce this bug with latest gcc-9 branch, I want to ask right away, if it is okay to back-port after a while. Boot-strapped and reg-tested on x86_64-pc-linux-gnu and armv7-linux-gnueabihf. Is it OK for trunk? Thanks, Bernd. 2019-07-30 Bernd Edlinger PR tree-optimization/91109 * lra-remat.c (update_scratch_ops): Remove assignment of the hard register. Index: gcc/lra-remat.c =================================================================== --- gcc/lra-remat.c (revision 273767) +++ gcc/lra-remat.c (working copy) @@ -1021,7 +1021,6 @@ get_hard_regs (struct lra_insn_reg *reg, int &nreg static void update_scratch_ops (rtx_insn *remat_insn) { - int hard_regno; lra_insn_recog_data_t id = lra_get_insn_recog_data (remat_insn); struct lra_static_insn_data *static_id = id->insn_static_data; for (int i = 0; i < static_id->n_operands; i++) @@ -1032,17 +1031,9 @@ update_scratch_ops (rtx_insn *remat_insn) int regno = REGNO (*loc); if (! lra_former_scratch_p (regno)) continue; - hard_regno = reg_renumber[regno]; *loc = lra_create_new_reg (GET_MODE (*loc), *loc, lra_get_allocno_class (regno), "scratch pseudo copy"); - if (hard_regno >= 0) - { - reg_renumber[REGNO (*loc)] = hard_regno; - if (lra_dump_file) - fprintf (lra_dump_file, " Assigning the same %d to r%d\n", - REGNO (*loc), hard_regno); - } lra_register_new_scratch_op (remat_insn, i, id->icode); }