From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 1E17D3858D38 for ; Fri, 14 Oct 2022 18:03:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E17D3858D38 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-pj1-x102f.google.com with SMTP id a6-20020a17090abe0600b0020d7c0c6650so8649166pjs.0 for ; Fri, 14 Oct 2022 11:03:49 -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=u5/PQBzTGtYBRc8n5rE+ItQF4YGjuLZaBRSsBaER4KM=; b=Jag3pkvUToAKZ4NZZAQe9shAxKjSAfn5qaNV7rEEN33o5XAn1cyGsryNVNbahjYjOI KlnZnXmUrWpMhk1B0HA0kR9bJ/eGT8yGm5HJ/8XLgCGs5GyV164XbrGY4/6PvgfDfS15 dQYIuVaGi++VeueltAQcH+kS4eltEBPO5NucSmHLeTZqkNLVZMLh0BZK+/o7ZD1s5xKr K+xQAQpvdPB5DSBTDWCbWlbxQ96OtFLmk0XRDvc0V9IhxL+uPyxr5va4ZWCVi/pVd+gi qgKhTioDVcNoMrBMgVIx5JfZM3rGN2VALfxhU3+Kqq41xidzQG2UTcoQ9cB+OSzK0QeL m6Pw== 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=u5/PQBzTGtYBRc8n5rE+ItQF4YGjuLZaBRSsBaER4KM=; b=BQ7ER4LMRR5zgDxbHI0o5IxbNW3SnMYe7MgAjip41WYey7CJTPeXHCfu/Ya3uzC7x7 zisoVpqxA33b/gnOQJgEsoPdFkvTDHKubvmmQxBQwEBQa2ZZmZPiZ0ySEbcy9kTLcNZq MnZtmXQ7wDzc0ssYJ1f6nDd5ZuVMafsZJ9yG8ZMnsRzT0O7LhqrMIFZaQb9IQeBQwZtM SbN35CEmfOTRlCNey0OKJoEpDYfQgS17kdIqCJnxBkq7t3O/uovGkkicLSAynEqGss8b O3/sgJUTkKhzggK8WBZoyhXfw0LcbXnTHvU4xaGDrdnimS+oTvCY2OW5JKfrgAvuuu/y CRwA== X-Gm-Message-State: ACrzQf3kuRxoPsRfJGgUykIGBzDjcb9DHiLUNk8I8Z0HnpENnwulE+Pd LQCy/Zh/NTjkaO7z3+ps6Oc= X-Google-Smtp-Source: AMsMyM7jx3/UnJC890R40wIcfG4CQD1qj3BWoQOklT8zFgeCpTdj6RjoDEBUhXsjHrzfvOZpHlA4dQ== X-Received: by 2002:a17:902:d4c1:b0:176:b795:c639 with SMTP id o1-20020a170902d4c100b00176b795c639mr6275489plg.154.1665770627821; Fri, 14 Oct 2022 11:03:47 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id f17-20020a170902ce9100b00172f4835f60sm2010467plg.189.2022.10.14.11.03.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 11:03:47 -0700 (PDT) Message-ID: <7b04be7e-d27d-0099-6631-6a764aed2cd7@gmail.com> Date: Fri, 14 Oct 2022 12:03:46 -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> <20221014173516.GF25951@gate.crashing.org> From: Jeff Law In-Reply-To: <20221014173516.GF25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,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 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. > 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? Agreed. jeff