From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 35B553858D28 for ; Wed, 24 May 2023 13:23:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 35B553858D28 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-x22a.google.com with SMTP id 38308e7fff4ca-2af290cf9b7so11516501fa.3 for ; Wed, 24 May 2023 06:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684934596; x=1687526596; 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=V0BmB0k6mng+0maBTuHnssBA307Nmi9hD0ANH3l2o4Q=; b=rysd+MzbpHCbwLY/JS4hM1eMjPIPZN6bEJn/tl0qx16Aocff7hAtDbVGugFGrex5Zs M0pHcIS/9LVXB90pXjUBukheuwmlIasCi6rl96XcEfwbdujEX9HN9uXudLUXv+0MvmYU EnPf4PUE6Iw6vcABruodFZY6m27edp7g/Kyboe4ZjBWXIr9EgAUCA4kBQMi101AbEi5X v8B5X7j0ur9atUiNY3LYb/iYbT+HEyd8yYUmkYeJQUYk8idcs4/ZbqvnmpW8BcRATGIE wuH6gm0Emabs7HNlrs7lzdFfB4fCDw8K0A5izXy/qUrkJ5d3W/jFD6HM8qAvtHgOiBj4 5QtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684934596; x=1687526596; 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=V0BmB0k6mng+0maBTuHnssBA307Nmi9hD0ANH3l2o4Q=; b=EoXdrOF5+gBrEISOru/a+kzbHxNCAAMQ2VFEMdyjJxvkyYv3zNWu8zuefu31/ihDmt 724sh9VTy4ij3VOVoe7RiwzEO7quH3gnOlD7TQ32S7M0kxKA6iNP1HJ2uhY7FbzNF9YD 6YjmahawXjU6PX+MjRB0/i+3TG9onMhwCM38nav3WyUTrDyxycQGCYdCk0Yn9ZRfGtSu WgzUroaJmgy0NlcnaITpr8L21z1O3hac2N5+aKtPphbg6OXYM1qfEgBkbQyNv9k5HI4+ jfT6ZvYgGDYMUdSxAoFX9OEzpOV5i9np7GHcQyOhHk0nmi/770Eci/jQ0jYxl99tiwz9 cKMw== X-Gm-Message-State: AC+VfDzGBGvOdYC6c49NJhOhNeWU3ZeiiKo6FGxpJVD8ef2oBvyhm9ky 0Y1f789GSkBSzvMP0xXeKRqOiVVnsyBQAX048ds9OUpO+SM= X-Google-Smtp-Source: ACHHUZ44hLzNICPyRYvx9xm/l6H5TZrtVbm3LqmX+Poiy1rupFpYCBfgl88g2bmllWd+SQWHHEVaRZvLk5VYTwDxx6s= X-Received: by 2002:a2e:b301:0:b0:2a6:16b5:c658 with SMTP id o1-20020a2eb301000000b002a616b5c658mr6576175lja.31.1684934595729; Wed, 24 May 2023 06:23:15 -0700 (PDT) MIME-Version: 1.0 References: <20230524125332.30839-1-amonakov@ispras.ru> In-Reply-To: <20230524125332.30839-1-amonakov@ispras.ru> From: Richard Biener Date: Wed, 24 May 2023 15:21:09 +0200 Message-ID: Subject: Re: [PATCH] doc: clarify semantics of vector bitwise shifts To: Alexander Monakov Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,THIS_AD,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 Wed, May 24, 2023 at 2:54=E2=80=AFPM Alexander Monakov via Gcc-patches wrote: > > Explicitly say that bitwise shifts for narrow types work similar to > element-wise C shifts with integer promotions, which coincides with > OpenCL semantics. Do we need to clarify that v << w with v being a vector of shorts still yields a vector of shorts and not a vector of ints? Btw, I don't see this promotion reflected in the IL. For typedef short v8hi __attribute__((vector_size(16))); v8hi foo (v8hi a, v8hi b) { return a << b; } I get no masking of 'b' and vector lowering if the target doens't handle it yields short int _5; short int _6; _5 =3D BIT_FIELD_REF ; _6 =3D BIT_FIELD_REF ; _7 =3D _5 << _6; which we could derive ranges from for _6 (apparantly we don't yet). Even typedef int v8hi __attribute__((vector_size(16))); v8hi x; int foo (v8hi a, v8hi b) { x =3D a << b; return (b[0] > 33); } isn't optimized currently (but could - note I've used 'int' elements here). So, I don't see us making sure the hardware does the right thing for out-of bound values. Richard. > gcc/ChangeLog: > > * doc/extend.texi (Vector Extensions): Clarify bitwise shift > semantics. > --- > gcc/doc/extend.texi | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index e426a2eb7d..6b4e94b6a1 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -12026,7 +12026,12 @@ 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@}}@. When the base type is narrower than @code{int}, > +element-wise shifts are performed as if operands underwent C integer > +promotions, like in OpenCL. This makes vector shifts by up to 31 bits > +well-defined for vectors with @code{char} and @code{short} base types. > + > +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 >