From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127925 invoked by alias); 12 Sep 2018 11:30:51 -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 121002 invoked by uid 89); 12 Sep 2018 11:29:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= 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; Wed, 12 Sep 2018 11:29:44 +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 1g03L4-0001YX-8E from Andrew_Stubbs@mentor.com ; Wed, 12 Sep 2018 04:29:42 -0700 Received: from [172.30.89.96] (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; Wed, 12 Sep 2018 12:29:37 +0100 Subject: Re: [PATCH 04/25] SPECIAL_REGNO_P To: Jeff Law , References: <85ef6d30-228a-af0f-55ef-dfde8e89f36f@redhat.com> From: Andrew Stubbs Message-ID: Date: Wed, 12 Sep 2018 11:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <85ef6d30-228a-af0f-55ef-dfde8e89f36f@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00601.txt.bz2 On 11/09/18 23:42, Jeff Law wrote: > This feels like you're papering over a problem in regrename and/or the > GCN port.. regrename should be checking the predicate and constraints > when it makes changes. And I think that you're still allowed to refer > to a fixed register in alternatives. I think you're allowed to use a constraint to match an already-present hardreg, fixed or otherwise, but my understanding is that LRA will never convert a pseudoreg to a fixed hardreg, no matter what the constraint says. Just to make sure, I just tried to fix EXEC (the only register matching the "e" constraint, and one of the "special" ones), and as expected the compiler blows up with "unable to generate reloads for ...". Anyway, back to the issue of SPECIAL_REGNO_P ... I've just retested the motivating example that we had, and that no longer fails in regrename. That could be because the problem is fixed, or simply that the compiler no longer generates the exact instruction sequence that demonstrates the problem. If I can't reproduce the issue then this macro becomes just a small compile-time optimization and we can remove it safely. I'll report back when I've done more testing. Andrew