From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F1D5D3858D32 for ; Mon, 27 Feb 2023 20:54:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1D5D3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677531254; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=Isrwi2DmZqyBDVwIir6gU3yYcuyJ3mzVOHWaycGdLdY=; b=NV6R/UILlNdG56D763vLv19bXTR5oixzO7ER/e1b43SowHzwah42rsGPP3t4Pm9iU3LZzD fz2AN0+q/I22/9B/kTztUtFPW90h6fSyzTpM/sWc5rH8unrdpKvTNdLJEMR8963W5KKFlN heL7Ib1lcjZwg8CfivJADOg7eEo1clg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-541-9S7ibiX-P7mgTVps711QQg-1; Mon, 27 Feb 2023 15:54:11 -0500 X-MC-Unique: 9S7ibiX-P7mgTVps711QQg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DC1AD85C6F4; Mon, 27 Feb 2023 20:54:10 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.101]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 964EB140EBF4; Mon, 27 Feb 2023 20:54:10 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 31RKs7Hi967356 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 27 Feb 2023 21:54:08 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31RKs6g5967355; Mon, 27 Feb 2023 21:54:06 +0100 Date: Mon, 27 Feb 2023 21:54:06 +0100 From: Jakub Jelinek To: Richard Biener , gcc-patches@gcc.gnu.org, Segher Boessenkool , richard.sandiford@arm.com Subject: Re: [PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham 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, 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. 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. Jakub