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 8787B3858D39 for ; Mon, 6 Mar 2023 18:14:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8787B3858D39 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 326IDJQJ013273; Mon, 6 Mar 2023 12:13:19 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 326IDIET013271; Mon, 6 Mar 2023 12:13:18 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 6 Mar 2023 12:13:18 -0600 From: Segher Boessenkool To: Jakub Jelinek Cc: 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: <20230306181318.GO25951@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.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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 05:18:50PM +0100, Jakub Jelinek wrote: > On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches wrote: > 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). It is running. Still without x86 though, but I'll add that later hopefully, also for the previous runs. > 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. nonzero_bits cannot be used in insn conditions. This is a well-known long-standing problem. The problem is that it can give different output in the passes after combine than it does in combine itself, since combine does more thorough analysis. This than causes insns generated in combine to no longer be recognised later -> kaboom, ICE. > Could we have a target hook to canonicalize memory addresses for combiner, > like we have that targetm.canonicalize_comparison ? If it makes sense, sure. And it is implemented in a sensible spot. It has to stay maintainable :-) Looking foreward to a patch, Segher