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 2CA043858D28 for ; Wed, 24 May 2023 14:21:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2CA043858D28 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 DDF3A44C1024; Wed, 24 May 2023 14:21:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru DDF3A44C1024 Date: Wed, 24 May 2023 17:21:38 +0300 (MSK) From: Alexander Monakov To: Richard Biener cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] doc: clarify semantics of vector bitwise shifts In-Reply-To: Message-ID: References: <20230524125332.30839-1-amonakov@ispras.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1181321728-1684938098=:29005" X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,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-1181321728-1684938098=:29005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 24 May 2023, Richard Biener wrote: > On Wed, May 24, 2023 at 2:54 PM 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? I don't think so, but if necessary we could add "and the result was truncated back to the base type": When the base type is narrower than @code{int}, element-wise shifts are performed as if operands underwent C integer promotions, and the result was truncated back to the base type, like in OpenCL. > 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 = BIT_FIELD_REF ; > _6 = BIT_FIELD_REF ; > _7 = _5 << _6; > > which we could derive ranges from for _6 (apparantly we don't yet). Here it depends on how we define the GIMPLE-level semantics of bit-shift operators for narrow types. To avoid changing lowering we could say that shifting by up to 31 bits is well-defined for narrow types. RTL-level semantics are also undocumented, unfortunately. > Even > > typedef int v8hi __attribute__((vector_size(16))); > > v8hi x; > int foo (v8hi a, v8hi b) > { > x = a << b; > return (b[0] > 33); > } > > isn't optimized currently (but could - note I've used 'int' elements here). Yeah. But let's constrain the optimizations first. > So, I don't see us making sure the hardware does the right thing for > out-of bound values. I think in practice it worked out even if GCC did not pay attention to it, because SIMD instructions had to facilitate autovectorization for C with corresponding shift semantics. Alexander > > 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@} == @{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 > > > --8323328-1181321728-1684938098=:29005--