From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15768 invoked by alias); 10 Dec 2018 15:22:08 -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 15758 invoked by uid 89); 10 Dec 2018 15:22:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=situations, Sandiford, sandiford, HTo:U*law X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Dec 2018 15:22:06 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gWNNj-0003yF-RZ from Andrew_Stubbs@mentor.com ; Mon, 10 Dec 2018 07:22:03 -0800 Received: from [172.30.89.167] (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 10 Dec 2018 15:21:59 +0000 Subject: Re: [PATCH 01/10] Fix IRA ICE. To: Jeff Law , , References: <87y390tdtq.fsf@arm.com> <0b673e60-26b4-d636-f75c-09d05b104a8e@redhat.com> From: Andrew Stubbs Message-ID: Date: Mon, 10 Dec 2018 15:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0b673e60-26b4-d636-f75c-09d05b104a8e@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-12/txt/msg00582.txt.bz2 On 08/12/2018 16:23, Jeff Law wrote: > On 12/8/18 5:14 AM, Richard Sandiford wrote: >> Andrew Stubbs writes: >>> On 21/11/2018 00:47, Jeff Law wrote: >>>> This seems like a really gross hack and sets an expectation that >>>> generating registers in the target after IRA has started is OK. It is >>>> not OK. THe fact that this works is, IMHO, likely an accident. >>> >>> What's the proper test for this? Neither lra_in_progress nor >>> reload_in_progress is set here, and can_create_pseudos returns true. >>> >>> The patterns have the ability to not generate registers, but they don't >>> know not to. >>> >>> Richard Sandiford has stated that it should be OK, but perhaps the other >>> architectures also work by accident? >> >> Yeah, my understanding was that targets could create new registers here, >> and I thought targets did in some situations. But that's also why I'm >> suspicious of the patch. If GCN is doing something valid and IRA isn't >> coping, then the patch seems to be fixing the problem in the wrong place. > IRA/LRA can create new pseudos internally. What I'm much less sure > about is whether or not the target can create them. WHen IRA/LRA > creates one internally it has the chance to update the various internal > structures it needs. That can't happen with a pseudo created by the > target this late. Vlad would know for sure. In any case, the new patch series that I will post soon does not appear to need this patch any more. (I'll post that as soon as I figure out an unrelated problem with jump threading.) Andrew