From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 592913858C56 for ; Fri, 14 Oct 2022 04:47:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 592913858C56 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-x52b.google.com with SMTP id r18so3330363pgr.12 for ; Thu, 13 Oct 2022 21:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=fTo3FdX/m2jPumwMK9PKeEva6ogCGEktPpeUeF7oai4=; b=D/Wg/DVpdZSaVt7J7YjgGcbDc3PDklu0X1whuSVbSvUu2xqwGGsYRuDo9rUmLyfNjR HqLATCUxAjEURsqgO32q39j/H898+/M916w1r8HvgorDdHiOQQaKOFbeLZ7+hvZzqm+t xohKJnlDvVck0QULy3bChNJ9Gcr1pSFvxA1BB1FE2YI918RgWlw1ru8WciL/xa4M8GWW pePVBdw262T23cEobu5ugLNp8dZkmqeOwrVV9gtPgcav8XEbhXagYPYagU8wE6EJXMbw eSpYwmvQfiIUuksvE02owt/+5kEP8qEXqiDqLUw8imbWyiCFe0Ddc4qN4AADVS3jJeyv LO9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references: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=fTo3FdX/m2jPumwMK9PKeEva6ogCGEktPpeUeF7oai4=; b=q14H9X0PUAEMFkv2ZneltsXySroyB0YmCyFJK35WHzS/trlXZn++ipsSeVcFSY+f4u RlbcspFZhy8AbrFUMCevhOafXUPTzr5pA9CC8lIKh0uRkW6a/OKxaj+DJOJaMZzCDWf1 o67lKVa/F/QW4rsKTBtBx8jsy+mhB7j3Ad2iI25lB8AgVKl/lPiPHxtqXpMe/4GTw50J c+497XjDsMeU929s9hTfpm3fp/Xdlc5hQQg+GT8MiTPeb2FFpvuGWYsQshN1kRwqVjXR 1NkfCtAsVfwB8qYqwaPfHUXqhrNJUoYnPJKrxskEFdgmUvKC4vs63gWxWqCqSaGMhJxw KVmw== X-Gm-Message-State: ACrzQf1d68c2D4tRpjnfzVRJ/nR3VkFKIajhCyR36GxKbGgNd3KxlV0w ex/5EEQBAUJ3/yYBWxLP/ZqQO/dbD9LVlg== X-Google-Smtp-Source: AMsMyM5FlNN+IcQUGwBxv79lzuOj34JbVOScEZGX5j7dQkZpEGzr1Ni8YngBXerAYzlUlIKSL2pErA== X-Received: by 2002:a63:24d:0:b0:452:87c1:9781 with SMTP id 74-20020a63024d000000b0045287c19781mr2989954pgc.512.1665722842098; Thu, 13 Oct 2022 21:47:22 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id c185-20020a621cc2000000b00561e8bbfa3dsm581866pfc.98.2022.10.13.21.47.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 21:47:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------v9SJy0JrljFochwvgTjHjgBL" Message-ID: Date: Thu, 13 Oct 2022 22:47:20 -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 , gcc-patches@gcc.gnu.org References: From: Jeff Law In-Reply-To: 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,HTML_MESSAGE,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: This is a multi-part message in MIME format. --------------v9SJy0JrljFochwvgTjHjgBL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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))) 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. Jeff --------------v9SJy0JrljFochwvgTjHjgBL--