From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1B0963858D39 for ; Mon, 6 Mar 2023 16:35:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B0963858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0940112FC; Mon, 6 Mar 2023 08:35:45 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B2E753F67D; Mon, 6 Mar 2023 08:35:00 -0800 (PST) From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek ,Segher Boessenkool , Jeff Law via Gcc-patches , Tamar Christina , Roger Sayle , Jeff Law , richard.sandiford@arm.com Cc: Segher Boessenkool , Jeff Law via Gcc-patches , Tamar Christina , Roger Sayle , Jeff Law Subject: Re: [PATCH] combine: Try harder to form zero_extends [PR106594] References: <000c01d94ec7$a6921430$f3b63c90$@nextmovesoftware.com> <20230304221749.GK25951@gate.crashing.org> <3b1ed616-5d90-7a66-63b5-bdb5e320eebf@gmail.com> <20230306135850.GN25951@gate.crashing.org> Date: Mon, 06 Mar 2023 16:34:59 +0000 In-Reply-To: (Jakub Jelinek's message of "Mon, 6 Mar 2023 17:18:50 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-27.9 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Jakub Jelinek writes: > On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches wrote: >> Segher Boessenkool writes: >> > On Mon, Mar 06, 2023 at 12:47:06PM +0000, Richard Sandiford wrote: >> >> How about the patch below? >> > >> > What about it? What would make it any better than the previous? >> >> It does what Jeff suggested in the quoted message: work within the existing >> extract/make_compound_operation scheme rather than try to opt out of it. > > That still feels like it could be risky in stage4, affecting various other > FEs which would be expecting ANDs in their patterns instead of *_EXTEND, no? > So, at least we'd need something like Segher ran to test it on various > targets on Linux kernel (but would be really nice to get also i?86/x86_64). > > If it were on the aarch64 side just one pattern, I'd suggest a pre-reload > splitter, but unfortunately the sign extends (and zero extends?) are handled > in legitimate address hook. Also, I see nonzero_bits only called in > rs6000's combine splitter and s390'x canonicalize_comparison target hook, > nowhere else in the backends, so I think using it outside of the combiner > isn't desirable. > > 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. 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 :-) 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. Thanks, Richard