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 D32393858D39 for ; Mon, 6 Mar 2023 18:32:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D32393858D39 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 326IVqTa014309; Mon, 6 Mar 2023 12:31:52 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 326IVq0J014308; Mon, 6 Mar 2023 12:31:52 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 6 Mar 2023 12:31:51 -0600 From: Segher Boessenkool To: Jakub Jelinek , Jeff Law via Gcc-patches , Tamar Christina , Roger Sayle , Jeff Law , richard.sandiford@arm.com Subject: Re: [PATCH] combine: Try harder to form zero_extends [PR106594] Message-ID: <20230306183151.GP25951@gate.crashing.org> References: <000c01d94ec7$a6921430$f3b63c90$@nextmovesoftware.com> <20230304221749.GK25951@gate.crashing.org> <3b1ed616-5d90-7a66-63b5-bdb5e320eebf@gmail.com> <20230306135850.GN25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_MANYTO,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 Mon, Mar 06, 2023 at 04:34:59PM +0000, Richard Sandiford wrote: > Jakub Jelinek writes: > > Could we have a target hook to canonicalize memory addresses for combiner, > > like we have that targetm.canonicalize_comparison ? > > I don't think a hook makes sense as a long-term design decision. > The canonicalisation we're doing here isn't logically AArch64-specific, > and in general, the less variation in RTL rules between targets, the better. Some targets do not want all insasnity allowed for other targets. We have quite a few exampples of this already. But of course a hook like the proposed one can be abused a lot to do completely unrelated things. We'll just have to trust target maintainers to have good taste and some wisdom (because not everyine else looks at all target patches). What else is new :-) > But if you mean adding target control as a GCC 13 hack, to avoid any > effect on other targets, then TBH, I'd prefer just sticking it in an > #ifdef GCC_AARCH64_H :-) And I will NAK that for all the same reasons: it is unmaintainable, it makes things harder instead of solving problems, it is a completely ad-hoc code change. > That makes it 100% clear that it's a > temporary hack to restrict the target impact rather than something > based on fundamentals. We can then revisit for GCC 14. And that will never happen, you know this as well as anyone else :-( Most importantly, what makes you think this is a problem for aarch64 only? If it actually is, you can fix it in the aarch64 config! Either with or without new hooks, whatever works best. Segher