From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 81DC43858D3C for ; Fri, 2 Jun 2023 09:40:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 81DC43858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2afb2874e83so26681081fa.0 for ; Fri, 02 Jun 2023 02:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685698809; x=1688290809; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kwzgnUsiHEKBSeZ2oF+2nIcm/j2E2VbgfGG+PUKlFSw=; b=Pp9ukgYU5DHQe1M25NhCT+cJhVypx5SrdAlhOowqJVPKW386Xijz3HniIq+vSFpT80 VyPnL9AY8FokkTXDnot7mIP7Msb1hepTOXrwO/yCLbSDeSJT49hZi2NbWjR0xs/JfPo3 zwIguVaEmWeKBwjkdReq0C0Bnl8vbmSTPn/XDhUNe6Ae9HaGOx6mQ5RlWQTH8r48wSCu 6o3eGCD4bsqHyW8irT2I+m0WjYKUN+OJak6URGp9RGKCWdFyDpmgh2falP7WY4zn0/2d GVyZXTdrB9Fin8DIHmVHvJorg9XIAvMHZBdCH0AKd1NueUtYxhHm3jeBtS0alEgUM/iU U7rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685698809; x=1688290809; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kwzgnUsiHEKBSeZ2oF+2nIcm/j2E2VbgfGG+PUKlFSw=; b=A+5+XlE8nCR7N1fdYJQ+R44+CLfGRIPrfkVVmCtJTR16Bxnf+yEve6X/KBU8S3+C8M ueYMh9VvC9r9n1mnhZm5iq7Y1CzUCq21pkHonKTmuJnLKUAoldUG83o17+OGE/Yfb+1E rsjwrAKsNXVm8kvg59L4m43O1YJ27WfbV6mAhfL0D4R/1WiP1n8T4lzfb51bIfzwA42Q 6JoEgiL5buH197CLFlIPW5tCe0synmu6dZsvzcDg4D3NNYeMVTlDQohYHxp5c323dmOq 6Jm3cF8VTh3BYk/oTTr2sJT88BpfFYc+GAPfRtxqAQI+MYxgGvjrooLAAhhzwg1mZI9G FHJA== X-Gm-Message-State: AC+VfDw4ymI1zKGjmOz43uMAEN/Xoa44uHghyyTM6dbTRdezOv0XQsyu GYT+8H5VWpRK4efYIyjV7UBCv+kJ/9ZmpEh+WFwUnNfn X-Google-Smtp-Source: ACHHUZ7/r3qrKpVnh9aBikCzvijpzQu5ZFJgTlntiJdaYz0H1smP18sqc7e3/afMeG88rxEUb0oiBJ3maIv8Psohym8= X-Received: by 2002:a2e:9944:0:b0:2ad:8623:a97e with SMTP id r4-20020a2e9944000000b002ad8623a97emr1044226ljj.50.1685698808641; Fri, 02 Jun 2023 02:40:08 -0700 (PDT) MIME-Version: 1.0 References: <4b477e8c-f8e6-5587-23ed-540f0c28ea05@ispras.ru> <8f166a4d-ec86-a95d-01d0-c381631da1df@ispras.ru> <952d17c5-265d-cb48-5dd8-bb50a9afc4b0@ispras.ru> In-Reply-To: <952d17c5-265d-cb48-5dd8-bb50a9afc4b0@ispras.ru> From: Richard Biener Date: Fri, 2 Jun 2023 11:39:55 +0200 Message-ID: Subject: Re: [PATCH] doc: clarify semantics of vector bitwise shifts To: Alexander Monakov Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 Thu, Jun 1, 2023 at 8:25=E2=80=AFPM Alexander Monakov wrote: > > > On Wed, 31 May 2023, Richard Biener wrote: > > > On Tue, May 30, 2023 at 4:49=E2=80=AFPM Alexander Monakov wrote: > > > > > > > > > On Thu, 25 May 2023, Richard Biener wrote: > > > > > > > On Wed, May 24, 2023 at 8:36=E2=80=AFPM Alexander Monakov wrote: > > > > > > > > > > > > > > > On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote: > > > > > > > > > > > I=E2=80=99d have to check the ISAs what they actually do here -= it of course depends > > > > > > on RTL semantics as well but as you say those are not strictly = defined here > > > > > > either. > > > > > > > > > > Plus, we can add the following executable test to the testsuite: > > > > > > > > Yeah, that's probably a good idea. I think your documentation chan= ge > > > > with the added sentence about the truncation is OK. > > > > > > I am no longer confident in my patch, sorry. > > > > > > My claim about vector shift semantics in OpenCL was wrong. In fact it= specifies > > > that RHS of a vector shift is masked to the exact bitwidth of the ele= ment type. > > > > > > So, to collect various angles: > > > > > > 1. OpenCL semantics would need an 'AND' before a shift (except VSX/Al= tivec). > > > > > > 2. From user side we had a request to follow C integer promotion sema= ntics > > > in https://gcc.gnu.org/PR91838 but I now doubt we can do that. > > > > > > 3. LLVM makes oversized vector shifts UB both for 'vector_size' and > > > 'ext_vector_type'. > > > > I had the impression GCC desired to do 3. as well, matching what we do > > for scalar shifts. > > > > > 4. Vector lowering does not emit promotions, and starting from gcc-12 > > > ranger treats oversized shifts according to the documentation you > > > cite below, and optimizes (e.g. with '-O2 -mno-sse') > > > > > > typedef short v8hi __attribute__((vector_size(16))); > > > > > > void f(v8hi *p) > > > { > > > *p >>=3D 16; > > > } > > > > > > to zeroing '*p'. If this looks unintended, I can file a bug. > > > > > > I still think we need to clarify semantics of vector shifts, but prob= ably > > > not in the way I proposed initially. What do you think? > > > > I think the intent at some point was to adhere to the OpenCL spec > > for the GCC vector extension (because that's a written spec while > > GCCs vector extension docs are lacking). Originally the powerpc > > altivec 'vector' keyword spurred most of the development IIRC > > so it might be useful to see how they specify shifts. > > It doesn't look like they document the semantics of '<<' and '>>' > operators for vector types. > > > 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 think for addition/multiplication of signed vectors everybody > expects them to have wrapping semantics without UB on overflow though? Actually GCC already treats them as UB on overflow by means of vector lowering eventually turning them into scalar operations and quite some patterns in match.pd applying to ANY_INTEGRAL_TYPE_P. > Revised patch below. The revised patch is OK. Thanks, Richard. > > It would be also good to amend the RTL documentation. > > > > It would be very nice to start an internals documentation section > > around collecting what the middle-end considers undefined > > or implementation defined (aka target defined) behavior in the > > GENERIC, GIMPLE and RTL ILs and what predicates eventually > > control that (like TYPE_OVERFLOW_UNDEFINED). Maybe spread it over > > {gimple,generic,rtl}.texi, though gimple.texi is only about the represe= ntation > > and all semantics are shared and documented in generic.texi. > > Hm, noted. Thanks. > > ---8<--- > > From e4e8d9e262f2f8dbc91a94291cf7accb74d27e7c Mon Sep 17 00:00:00 2001 > From: Alexander Monakov > Date: Wed, 24 May 2023 15:48:29 +0300 > Subject: [PATCH] doc: clarify semantics of vector bitwise shifts > > Explicitly say that attempted shift past element bit width is UB for > vector types. Mention that integer promotions do not happen. > > gcc/ChangeLog: > > * doc/extend.texi (Vector Extensions): Clarify bitwise shift > semantics. > --- > gcc/doc/extend.texi | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index e426a2eb7d..3723cfe467 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -12026,7 +12026,14 @@ elements in the operand. > It is possible to use shifting operators @code{<<}, @code{>>} on > integer-type vectors. The operation is defined as following: @code{@{a0, > a1, @dots{}, an@} >> @{b0, b1, @dots{}, bn@} =3D=3D @{a0 >> b0, a1 >> b1= , > -@dots{}, an >> bn@}}@. Vector operands must have the same number of > +@dots{}, an >> bn@}}@. Unlike OpenCL, values of @code{b} are not > +implicitly taken modulo bit width of the base type @code{B}, and the beh= avior > +is undefined if any @code{bi} is greater than or equal to @code{B}. > + > +In contrast to scalar operations in C and C++, operands of integer vecto= r > +operations do not undergo integer promotions. > + > +Operands of binary vector operations must have the same number of > elements. > > For convenience, it is allowed to use a binary vector operation > -- > 2.39.2