From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 42D353858C66 for ; Fri, 2 Jun 2023 09:24:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42D353858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 8F88044C100D; Fri, 2 Jun 2023 09:24:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 8F88044C100D Date: Fri, 2 Jun 2023 12:24:23 +0300 (MSK) From: Alexander Monakov To: Matthias Kretz cc: gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: [PATCH] doc: clarify semantics of vector bitwise shifts In-Reply-To: <3125723.CQOukoFCf9@minbar> Message-ID: References: <4506760.44csPzL39Z@minbar> <83e84153-b9e4-ecc9-5b6c-58637f3c61e8@ispras.ru> <3125723.CQOukoFCf9@minbar> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Fri, 2 Jun 2023, Matthias Kretz wrote: > > Okay, I see opinions will vary here. I was thinking about our immintrin.h > > which is partially implemented in terms of generic vectors. Imagine we > > extend UBSan to trap on signed overflow for vector types. I expect that > > will blow up on existing code that uses Intel intrinsics. > > _mm_add_epi32 is already implemented via __v4su addition (i.e. unsigned). So > the intrinsic would continue to wrap on signed overflow. Ah, if our intrinsics take care of it, that alleviates my concern. > > I'm not sure what you consider a breaking change here. Is that the implied > > threat to use undefinedness for range deduction and other optimizations? > > Consider the stdx::simd implementation. It currently follows semantics of the > builtin types. So simd can be shifted by 30 without UB. The > implementation of the shift operator depends on the current behavior, even if > it is target-dependent. For PPC the simd implementation adds extra code to > avoid the "UB". With nailing down shifts > sizeof(T) as UB this extra code now > needs to be added for all targets. What does stdx::simd do on LLVM, where that has always been UB even on x86? Alexander