> Am 24.05.2023 um 16:21 schrieb Alexander Monakov <amona...@ispras.ru>: > > >> On Wed, 24 May 2023, Richard Biener wrote: >>> On Wed, May 24, 2023 at 2:54 PM Alexander Monakov via Gcc-patches >>> <gcc-patches@gcc.gnu.org> 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 <a_1(D), 16, 0>; >> _6 = BIT_FIELD_REF <b_2(D), 16, 0>; >> _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.
I’d 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. I agree we can go with smaller types than int behave as if promoted (also for scalars for consistency). Those operations do not exist in the C standard after all (maybe with _BitInt it’s now a thing) Richard. > 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