From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20264 invoked by alias); 9 Aug 2019 10:32:02 -0000 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 Received: (qmail 20247 invoked by uid 89); 9 Aug 2019 10:32:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=H*c:Windows-1252, ahead X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092066082.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (40.92.66.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 10:32:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oYNEUJ9hkkj97gcE1O3v6eiSxtdep9d1PuQjBPqoaSGMmy2/rfedHwbb3CjvYc+0ZGl52LoEi0qYkdDQ2M+EJ2d6YrCKP/Dut3okO61a9qR6HiD9MdK01UJCUm5MP2GYMMNr4ylb03kwDTTbVCyaTwusZFZan8lkaSmYO+7MeDnpfSn7GEC/mO/I8Rd+mKlqrI3axPspnYGC+A7HqctShn5nJFB2V8rQ5B/HOWSmUg7ZOavAqAPLpasY6Yd7QvQiD2OHdMfce1MoO7JIWXEEPYYsuHtBW7Dvq2gZAqxKEAX472CZhiHk8jJWYH3QEXzagWuLIpj7y/nXHUTLLvNHqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ljHGAQYdEUG9idEJxoKkprjtnutdURh0SDl3pQVX0M=; b=lDFCl84juTlYLkaPB5D8M0Nf6Td/WXPhxJqSf8274qtlXFlYeNzybPpIAT6CT6Y7L1CKxiAr5mjMN/stAENQmX7IkQiDa8xkorGDElQ/WAXLrrmWlIwdb9idkzYfl2y19+0InSe5KlX2dt+HCKYzLfOEF40WzQpo/9SAQQFFQ2ZKX8qrWeXSqXVGID7dKu8bw553H3ZHlj/GQ6LFX0Mg/TArzT0PP/mXr8wg0z5gX8JGV5bOCiqY6/YUoAG/VxbrHzalyfQLtHtT+DplN/ZY0mv5drUBmidp6HTBRufy7Ram8ZoIXAmGN9ko372T+zcjOPO1Xj08P6/x+jqxhTHZFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR01FT022.eop-EUR01.prod.protection.outlook.com (10.152.0.51) by HE1EUR01HT181.eop-EUR01.prod.protection.outlook.com (10.152.1.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2157.15; Fri, 9 Aug 2019 10:31:57 +0000 Received: from VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM (10.152.0.57) by HE1EUR01FT022.mail.protection.outlook.com (10.152.0.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15 via Frontend Transport; Fri, 9 Aug 2019 10:31:57 +0000 Received: from VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM ([fe80::4c47:62c0:cf1:ba27]) by VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM ([fe80::4c47:62c0:cf1:ba27%7]) with mapi id 15.20.2157.020; Fri, 9 Aug 2019 10:31:57 +0000 From: Bernd Edlinger To: Vladimir Makarov , "gcc-patches@gcc.gnu.org" , Jakub Jelinek Subject: Re: [PATCH] [LRA] Fix wrong-code PR 91109 Date: Fri, 09 Aug 2019 10:59:00 -0000 Message-ID: References: <6a79fb83-d6d5-63fa-c16e-ccea9d2f93ca@redhat.com> In-Reply-To: <6a79fb83-d6d5-63fa-c16e-ccea9d2f93ca@redhat.com> x-microsoft-original-message-id: <41bc1755-cf3b-c379-b204-054c80587ea6@hotmail.de> x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-08/txt/msg00619.txt.bz2 Hi Jakub, I think this wrong code bug would be good to be fixed in 9.2. Would you like me to go ahead, or should it wait for 9.3 ? Thanks Bernd. On 8/7/19 3:32 PM, Vladimir Makarov wrote: > On 8/5/19 4:37 PM, Bernd Edlinger wrote: >> 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.=A0 That seems to be mostly because the live range >> info of the cloned schatch register is not working the way how update_sc= rach_ops >> sets up the new register.=A0 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 probl= em. >> >> 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-gnue= abihf. >> Is it OK for trunk? >=20 > Thank you for working on the problem which is severe as the wrong code is= generated.=A0 The patch is ok as an intermediate solution. You can commit = it to the trunk and gcc-9 branch. >=20 > Still I think more work on the PR is needed.=A0 If subsequent LRA sub-pas= s spills some pseudo to assign a hard register to the scratch of the remate= rialized insn as it was in the original insn, it might make this rematerial= ization unprofitable.=A0 So I'll think how to avoid the unprofitable remate= rialization in such cases and would like to work on this=A0 PR more. >=20 > Please, do not close the PR after committing the patch.=A0 I am going to = work on it more when stage3 starts. >=20 >=20