From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 102953858D38 for ; Fri, 14 Oct 2022 20:14:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 102953858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 29EKCoGL022982; Fri, 14 Oct 2022 15:12:50 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 29EKCnvm022976; Fri, 14 Oct 2022 15:12:49 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 14 Oct 2022 15:12:49 -0500 From: Segher Boessenkool To: "Koning, Paul" Cc: Jeff Law , GCC Patches Subject: Re: [PATCH] Always enable LRA Message-ID: <20221014201249.GG25951@gate.crashing.org> References: <20221014163700.GE25951@gate.crashing.org> <20221014173516.GF25951@gate.crashing.org> <7b04be7e-d27d-0099-6631-6a764aed2cd7@gmail.com> <64E0D774-6501-4AD7-8F2A-9AD18CF36CB0@dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64E0D774-6501-4AD7-8F2A-9AD18CF36CB0@dell.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Oct 14, 2022 at 07:58:39PM +0000, Koning, Paul wrote: > > On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches wrote: > > On 10/14/22 11:35, Segher Boessenkool wrote: > >> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote: > >>>> LRA only ever generates insns that pass recog. The backend allows this > >>>> define_insn, requiring it to be split (it returns template "#"), but > >>>> then somehow it doesn't match in any split pass? > >>> Nope. The elimination code will just change one register without > >>> re-recognizing. That's precisely what happens here. > >> That is a big oversight then. Please file a PR? > > > > Sure. But just recognizing (for this particular case) will just move the fault from a failure to split to a failure to recognize. From my wanderings in the elimination code, I don't see that it has a path that would allow it to reasonably handle this case -- ie, if the insn does not recognize, what then? Conceptually we need to generate an input-reload but I don't see a way to do that in the elimination code. Maybe Vlad knows how it ought to be handled. > > I probably have too simplistic a view of this, but the way I think of it is that LRA (and reload) make decisions subject to constraints, and among those constraints are the ones specified in the MD file patterns. That to me means that a substitution proposed to be made by the LRA code is subject to those invariants: it can't do that if the constraints say "no" and must then consider some other alternative. I think that is exactly right for LRA. Old reload conceptually changed the whole function all at once, starting with valid RTL, and ending with strictly valid RTL. LRA works locally, one instruction at a time essentially, and makes the changes immediately. If when it has finished work on the function offsets have changed, it walks over the whole function again, repeat until done. "Strictly valid" means that the constraints are considered, and the insn is only valid if some enabled alternative satisfies all constraints. I hope I got that all right, I'm not an expert! :-) Segher