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 C7522385800A for ; Fri, 14 Oct 2022 16:38:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7522385800A 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 29EGb1KC012045; Fri, 14 Oct 2022 11:37:01 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 29EGb0uj012044; Fri, 14 Oct 2022 11:37:00 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 14 Oct 2022 11:37:00 -0500 From: Segher Boessenkool To: Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Always enable LRA Message-ID: <20221014163700.GE25951@gate.crashing.org> References: 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=-1.6 required=5.0 tests=BAYES_00,BODY_8BITS,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: Hi! On Thu, Oct 13, 2022 at 10:47:20PM -0600, Jeff Law wrote: > On 10/13/22 17:56, Segher Boessenkool wrote: > >h8300 fails during GCC build: > >/home/segher/src/gcc/libgcc/unwind.inc: In function > >'_Unwind_SjLj_RaiseException': > >/home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not split insn > > 141 | } > > | ^ > >(insn 69 256 327 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [12 S4 A32]) > > (reg/f:SI 7 sp)) "/home/segher/src/gcc/libgcc/unwind.inc":118:12 > > 19 {*movsi} > > (expr_list:REG_ARGS_SIZE (const_int 4 [0x4]) > > (nil))) > >during RTL pass: final > >which looks like a backend bug, I don't see a pattern that could split > >this (without needing an extra clobber)? > > Really smells like an LRA bug to me. > > > We have this as we leave IRA: > > > (insn 10 9 11 2 (set (reg/f:SI 30) >        (plus:SI (reg/f:SI 11 fp) >            (const_int -4 [0xfffffffffffffffc]))) "j.c":31:7 264 > {*addsi} >     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 11 fp) >            (const_int -4 [0xfffffffffffffffc])) > (nil))) > (insn 11 10 12 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3  S4 A32]) >        (reg/f:SI 30)) "j.c":31:7 19 {*movsi} >     (expr_list:REG_DEAD (reg/f:SI 30) >        (expr_list:REG_ARGS_SIZE (const_int 4 [0x4]) >            (nil)))) > > > And as we leave LRA: > > (note 10 9 11 2 NOTE_INSN_DELETED) > (insn 11 10 13 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32]) >         (reg/f:SI 7 sp)) "j.c":31:7 19 {*movsi} >      (expr_list:REG_ARGS_SIZE (const_int 4 [0x4]) >         (nil))) 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? > 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)! Segher