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 6CD293858D32 for ; Mon, 27 Feb 2023 21:01:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6CD293858D32 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 24BDFC14; Mon, 27 Feb 2023 13:02:00 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C6193F99C; Mon, 27 Feb 2023 13:01:16 -0800 (PST) From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek ,Richard Biener , gcc-patches@gcc.gnu.org, Segher Boessenkool , richard.sandiford@arm.com Cc: Richard Biener , gcc-patches@gcc.gnu.org, Segher Boessenkool Subject: Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803] References: Date: Mon, 27 Feb 2023 21:01:15 +0000 In-Reply-To: (Jakub Jelinek's message of "Mon, 27 Feb 2023 21:54:06 +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=-28.6 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, Feb 27, 2023 at 08:43:27PM +0000, Richard Sandiford wrote: >> My argument was that !SHIFT_COUNT_TRUNCATED and >> C?Z_DEFINED_VALUE_AT_ZERO==0 mean that the behaviour is undefined >> only in the sense that target-independent code doesn't know what >> the behaviour is. !SHIFT_COUNT_TRUNCATED doesn't mean that >> target-independent code can assume that out-of-range shift values >> invoke program UB (and therefore target-independent code can optimise >> shifts on the principle that all shifts are in-range). Similarly >> CTZ_DEFINED_VALUE_AT_ZERO==0 doesn't mean the corresponding thing for CTZ. > > Even if the target-independent code doesn't know what the target dependent > code will do, I don't see how it could emit it safely. > In that case, I could understand some particular backend emitting such code > because it knows what to assume, and then generic code like simplify-rtx > simply trying to punt and not mess up with things which it doesn't know how > they'll behave. > But in this case it isn't aarch64 backend that emits this, but it is > the generic expansion code. It even guarantees one of the two shifts > will be out of bounds... And target didn't tell it that out of bound > shifts say won't trap or do something similar. But we haven't had to handle trapping shifts because no supported target behaves like that. And yeah, even if you disagree with that being a reasonable assumption... > Sure, there could be a target hook or macro that would tell the expander > that the backend out of bound shift will just produce unspecified result > but not other effects. ...adding an explicit control, or putting the expansion in aarch64 code, would allow us to generate the same RTL as we do now, and so hit the same bug. Richard