doc: clarify semantics of vector bitwise shifts
Checks
Commit Message
Explicitly say that bitwise shifts for narrow types work similar to
element-wise C shifts with integer promotions, which coincides with
OpenCL semantics.
gcc/ChangeLog:
* doc/extend.texi (Vector Extensions): Clarify bitwise shift
semantics.
---
gcc/doc/extend.texi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
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?
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). 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).
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@} == @{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
>
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.
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
> >
>
@@ -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