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 ADACB3858C53 for ; Fri, 2 Jun 2023 07:49:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADACB3858C53 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 35BFA44C100B; Fri, 2 Jun 2023 07:49:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 35BFA44C100B Date: Fri, 2 Jun 2023 10:49:26 +0300 (MSK) From: Alexander Monakov To: Matthias Kretz cc: Richard Biener , gcc-patches Subject: Re: [PATCH] doc: clarify semantics of vector bitwise shifts In-Reply-To: <4506760.44csPzL39Z@minbar> Message-ID: <83e84153-b9e4-ecc9-5b6c-58637f3c61e8@ispras.ru> References: <952d17c5-265d-cb48-5dd8-bb50a9afc4b0@ispras.ru> <4506760.44csPzL39Z@minbar> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1354089460-1685692166=:11079" 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1354089460-1685692166=:11079 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 2 Jun 2023, Matthias Kretz wrote: > On Thursday, 1 June 2023 20:25:14 CEST Alexander Monakov wrote: > > On Wed, 31 May 2023, Richard Biener wrote: > > > So yes, we probably should clarify the semantics to match the > > > implementation (since we have two targets doing things differently > > > since forever we can only document it as UB) and also note the > > > difference from OpenCL (in case OpenCL is still relevant these > > > days we might want to offer a -fopencl-vectors to emit the required > > > AND). > > > > It doesn't have to be UB, in principle we could say that shift amount > > is taken modulo some power of two depending on the target without UB. > > But since LLVM already treats that as UB, we might as well follow. > > I prefer UB (as your patch states 👍). If a user requires the AND, let them > state it explicitly. Don't let everybody pay in performance. What I suggested does not imply a performance cost. All targets take some lower bits of the shift amount anyway. It's only OpenCL's exact masking that would imply a performance cost (and I agree it's inappropriate for GCC's generic vectors). > > I think for addition/multiplication of signed vectors everybody > > expects them to have wrapping semantics without UB on overflow though? > > simd x = ...; > bool t = all_of(x < x + 1); // unconditionally true or not? > > I'd expect t to be unconditionally true. Because simd simply is a data- > parallel version of int. 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. But use of generic vectors in immintrin.h is our implementation detail, and people might have expected intrinsics to be overflow-safe, like for aliasing (where we use __attribute__((may_alias)) in immintrin.h). Although, we can solve that by inventing overflow-wraps attribute for types, maybe? > > Revised patch below. > > This can be considered a breaking change. Does it need a mention in the > release notes? 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? Thanks. Alexander --8323328-1354089460-1685692166=:11079--