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 719893858D38 for ; Fri, 14 Oct 2022 17:36:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 719893858D38 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 29EHZGEt015713; Fri, 14 Oct 2022 12:35:17 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 29EHZGYa015711; Fri, 14 Oct 2022 12:35:16 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 14 Oct 2022 12:35:16 -0500 From: Segher Boessenkool To: Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Always enable LRA Message-ID: <20221014173516.GF25951@gate.crashing.org> References: <20221014163700.GE25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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? > >>Register elimination ultimately discovered that (reg 30) was the same as > >>the stack pointer and did the natural substitution.    The natural > >>substitution results in invalid RTL and there's really no way to back > >>out and do something different AFAICT in lra-eliminations.cc. > >> > >>The only reason we fault is because the H8 backend knows this is invalid > >>RTL and refuses to split it.  If we were to try and re-recognize the > >>insn in question it would fail to recognize after the substitution > >>because the auto-inc'd operand overlaps with the other operand. > >But it *did* recog? Or does LRA somehow not always recog() everything? > >I always thought that was one of the huge improvements over old reload > >(it does everything very locally instead of very globally)! > > No, LRA does not force re-recognition in some cases, particularly for > register eliminations. It is the only way it can know if it needs to reload more. Even if it somehow can assume it doesn't have to check this in some cases, an assert (inside a CHECKING_P) would be nice? Segher