From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120813 invoked by alias); 7 Aug 2019 13:32:25 -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 120794 invoked by uid 89); 7 Aug 2019 13:32:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=H*c:windows-1252, solves, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Aug 2019 13:32:23 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A8E8C4ECE; Wed, 7 Aug 2019 13:32:22 +0000 (UTC) Received: from tobol.usersys.redhat.com (unused-10-15-17-174.yyz.redhat.com [10.15.17.174]) by smtp.corp.redhat.com (Postfix) with ESMTP id EAC9A600C6; Wed, 7 Aug 2019 13:32:21 +0000 (UTC) Subject: Re: [PATCH] [LRA] Fix wrong-code PR 91109 To: Bernd Edlinger , "gcc-patches@gcc.gnu.org" References: From: Vladimir Makarov Message-ID: <6a79fb83-d6d5-63fa-c16e-ccea9d2f93ca@redhat.com> Date: Wed, 07 Aug 2019 13:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00465.txt.bz2 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. 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? Thank you for working on the problem which is severe as the wrong code is generated.  The patch is ok as an intermediate solution. You can commit it to the trunk and gcc-9 branch. Still I think more work on the PR is needed.  If subsequent LRA sub-pass spills some pseudo to assign a hard register to the scratch of the rematerialized insn as it was in the original insn, it might make this rematerialization unprofitable.  So I'll think how to avoid the unprofitable rematerialization in such cases and would like to work on this  PR more. Please, do not close the PR after committing the patch.  I am going to work on it more when stage3 starts.