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 C05A13858D39 for ; Mon, 6 Mar 2023 22:59:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C05A13858D39 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 326MwpJg026704; Mon, 6 Mar 2023 16:58:52 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 326MwnUM026700; Mon, 6 Mar 2023 16:58:49 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 6 Mar 2023 16:58:49 -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: <20230306225849.GQ25951@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: > > 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. C1 is trunk, C2 is the previous patch, C3 is this one: $ perl sizes.pl --percent C[123] C1 C2 C3 alpha 7082243 100.066% 100.000% arc 4207975 100.015% 100.000% arm 11518624 100.008% 100.000% arm64 24514565 100.067% 100.033% armhf 16661684 100.098% 100.000% csky 4031841 100.002% 100.000% i386 0 0 0 ia64 20354295 100.029% 100.000% m68k 4394084 100.023% 100.000% microblaze 6549965 100.014% 100.000% mips 10684680 100.024% 100.000% mips64 8171850 100.002% 100.000% nios2 4356713 100.012% 100.000% openrisc 5010570 100.003% 100.000% parisc 8406294 100.002% 100.000% parisc64 0 0 0 powerpc 11104901 99.992% 100.000% powerpc64 24532358 100.057% 100.000% powerpc64le 21293219 100.062% 100.000% riscv32 2028474 100.131% 100.000% riscv64 9515453 100.120% 100.000% s390 20519612 100.279% 100.000% sh 0 0 0 shnommu 1840960 100.012% 100.000% sparc 5314422 100.004% 100.000% sparc64 7964129 99.992% 100.000% x86_64 0 0 0 xtensa 2925723 100.070% 100.000% It does absolutely nothing for all those other targets you say it is beneficial for; and it is a net *negative* for aarch64 itself! Segher