From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id D85963858D38 for ; Fri, 14 Oct 2022 17:07:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D85963858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x52d.google.com with SMTP id l6so4827203pgu.7 for ; Fri, 14 Oct 2022 10:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gMTbPzc0qk1nVlRtWZImI5pAgJ3JkJG8BMs8Wb6ip4M=; b=BmvKrqiXtyeJV5NRAdUhxTrKXPqulRhrePECV49hfooMLdxrraWfarFX0WRbmUP1MA f7zNkGkl0wjHNoyc06YYBFkaNA/ToPXC+6Iwayf4VjC5xuXjDp4Fh1TIujmeVs9sp1Np oaKoJyJbLmCAwwDUER1HARTXphyinbt2vcp0HU27qvtxA7C2VE7+3v+ax77hGEIYCONB c6ln6B0XIhK5B47bdMUMyuledMFsTO9Edwp7q+Y4ubw7R/kG/xRxKWXM3cB3FuVinUSL nNoh7oHuYOGn6RZwBvs5FthAsEMZbSwrVsjgY0WE6KhkkR8Q+W/MGpnxUw454jsd0eb3 bSHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gMTbPzc0qk1nVlRtWZImI5pAgJ3JkJG8BMs8Wb6ip4M=; b=UYjWuUrnvIJeCMdUXQ24s5viLFHKhTr3z7VTrCl7SIu/+KKerXd/9B4iQypMR/jsCT SfpY7g2aEm4PJI3IZjfEXck2vQgKfjxCK1cZ3anC0vy+YaZAX6l4ir0SWPGxBJhBL41L 0Kkp1SoCZvUtack3k6gLHLutgIilhq/Bf2xQQigXjHEY569cMaIbDSkWPb4CNFw1EW0X NM1TkxoqTsgamUrOYHhO0zs60zpDragQp5riAfkLHi9jsH6+fbzqe7NBTJBONgYd0kSB /q0+osTkQ6IZuuG4O+baLJR+9yVwLAov8jx2YfNjhhdQJZ2BoYuiULMfGYJZntt252Ci JAZQ== X-Gm-Message-State: ACrzQf0iePq3NjmbRfePEouKOlCrmxepmDGsg10TYs9v7HGsBeWwN6e1 /pVLmPwXe14h1V8G+Qm3r+I= X-Google-Smtp-Source: AMsMyM73OOAtaHf1ouMnVNuGZCs2Gmslaxvi0I7iIAvZ+X47QJhSksctim+MNgHU0EL4RukcLjhOOg== X-Received: by 2002:a63:1e10:0:b0:439:3c93:25ab with SMTP id e16-20020a631e10000000b004393c9325abmr5501489pge.317.1665767265597; Fri, 14 Oct 2022 10:07:45 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id h9-20020a656389000000b00458a0649474sm1669594pgv.11.2022.10.14.10.07.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 10:07:45 -0700 (PDT) Message-ID: Date: Fri, 14 Oct 2022 11:07:43 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Always enable LRA Content-Language: en-US To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org References: <20221014163700.GE25951@gate.crashing.org> From: Jeff Law In-Reply-To: <20221014163700.GE25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 10/14/22 10:37, Segher Boessenkool wrote: > 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? Nope.  The elimination code will just change one register without re-recognizing.  That's precisely what happens here. > >> 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. jeff