From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116665 invoked by alias); 16 Aug 2019 15:19:03 -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 116585 invoked by uid 89); 16 Aug 2019 15:19:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=satisfies, rx 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; Fri, 16 Aug 2019 15:19:01 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F1769C05AA6B; Fri, 16 Aug 2019 15:18:59 +0000 (UTC) Received: from [10.10.120.77] (ovpn-120-77.rdu2.redhat.com [10.10.120.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9D452A8421; Fri, 16 Aug 2019 15:18:59 +0000 (UTC) Subject: Re: [PATCH] [LRA] Fix wrong-code PR 91109 take 2 From: Vladimir Makarov To: Bernd Edlinger , "gcc-patches@gcc.gnu.org" References: <6a79fb83-d6d5-63fa-c16e-ccea9d2f93ca@redhat.com> <6ef8ef98-f7aa-3809-ba2d-4be618c12138@redhat.com> Message-ID: <4b5ab04e-74fe-9858-c434-f1d78384aa4c@redhat.com> Date: Fri, 16 Aug 2019 15:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <6ef8ef98-f7aa-3809-ba2d-4be618c12138@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg01181.txt.bz2 On 2019-08-16 11:06 a.m., Vladimir Makarov wrote: > > On 2019-08-15 3:46 p.m., Bernd Edlinger wrote: >> Hi, >> >> as discussed in the PR 91109 audit trail, >> my previous patch missed a case where no spilling is necessary, >> but the re-materialized instruction has now scratch regs without >> a hard register assignment.  And thus the LRA pass falls out of >> the loop pre-maturely. >> >> Fixed by checking for scratch regs with no assignment >> and continuing the loop in that case. >> >> >> Boot-strapped and reg-tested on x86_64-pc-linux-gnu and >> arm-linux-gnueabihf. >> Is it OK for trunk? > > Sorry, I am afraid this patch can make LRA cycle forever in some cases. > > The reason for this is an existing pattern (scratch "r,X").  So if LRA > makes a choice for the 2nd alternative, it will be a former spilled > scratch (such spilled pseudo is changed into scratch at the end of > LRA).  In this case the constraint subpass satisfies all constraints. > There are no changes at all but because there are spilled (not in > remat subpass) former scratches we continue the loop. > > I guess you need something more accurate interaction with remat subpass. > > Sorry, I missed that your new code is run only if remat returns true which means some changes in it.  It was not seen in the patch context.  So there will be no cycling as remat at some point stop to do changes. The patch is ok for trunk and gcc-9 branch. Thank you, Bernd