From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13244 invoked by alias); 2 Oct 2019 00:07:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13207 invoked by uid 89); 2 Oct 2019 00:07:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HContent-Transfer-Encoding:8bit X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2019 00:07:38 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x9207Xcg010481; Tue, 1 Oct 2019 19:07:33 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x9207XxM010480; Tue, 1 Oct 2019 19:07:33 -0500 Date: Wed, 02 Oct 2019 00:07:00 -0000 From: Segher Boessenkool To: Andrew Stubbs Cc: Richard Sandiford , GCC Development Subject: Re: RTL alternative selection question Message-ID: <20191002000732.GC9749@gate.crashing.org> References: <1a7febb4-197e-eca7-4fcf-99bf5cb8bdf6@mentor.com> <20190923141517.GH9749@gate.crashing.org> <57be9ba9-94b3-3aea-37ce-ca2cd55bd34c@mentor.com> <4e2f4125-a19d-aef2-77f7-ba65d7f2b528@mentor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4e2f4125-a19d-aef2-77f7-ba65d7f2b528@mentor.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00018.txt.bz2 On Tue, Oct 01, 2019 at 01:12:06PM +0100, Andrew Stubbs wrote: > On 23/09/2019 15:39, Andrew Stubbs wrote: > >On 23/09/2019 15:15, Segher Boessenkool wrote: > >>On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote: > >>>   [(set (match_operand:DI 0 "register_operand"  "=Sg,v") > >>>         (ashift:DI > >>>           (match_operand:DI 1 "gcn_alu_operand" " Sg,v") > >>>           (match_operand:SI 2 "gcn_alu_operand" " Sg,v"))) > >>>    (clobber (match_scratch:BI 3                 > >>>"=cs,X"))] > >> > >>>Unfortunately, the compiler (almost?) exclusively selects the second > >>>alternative, even when this means moving the values from one register > >>>file to the other, and then back again. > >>> > >>>The problem is that the scalar instruction clobbers the CC register, > >>>which results in a "reject++" for that alternative in the LRA dump. > >> > >>What kind of reject?  It prints a reason, too. > > > >      0 Non input pseudo reload: reject++ > > Apparently I was confused by operand "0" versus alternative "0". That > message did occur, but it wasn't the only one. Here's all of it: > > 0 Non input pseudo reload: reject++ > 3 Scratch win: reject+=2 > alt=0,overall=9,losers=1,rld_nregs=2 > alt=1,overall=6,losers=1,rld_nregs=2 > > I don't understand why the "reject++" occurs, but presumably has to do > with the "Sg" register availability somehow? operands[0] (the output) needed a reload, apparently. [ snip ] > Unfortunately, removing the "Scratch win" penalty alone is not enough > for LRA to select the first alternative -- at least, no in my testcase > -- so I need to understand the "non input pseudo reload" issue as well. > I can see why it fires for alt0, but not why it does not fire for alt1. The reload it decided to do there was for operands[1] or operands[2]? Segher