[Bug tree-optimization/101187] New: enhancement for vector shift with constant bigger than element precision

[Bug tree-optimization/101187] New: enhancement for vector shift with constant bigger than element precision

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

            Bug ID: 101187
           Summary: enhancement for vector shift with constant bigger than
                    element precision
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: jakub at redhat dot com, rguenth at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

using T = unsigned char; // or ushort, or uint
using V [[gnu::vector_size(8)]] = T;
V f(V x) { return x >> 8 * sizeof(T); }

r12-1764 regresses pr91838.C with extra options: -march=cascadelake

cat pr91838.C

/* { dg-do compile { target c++11 } } */
/* { dg-additional-options "-O2 -Wno-psabi -w" } */
/* { dg-additional-options "-masm=att" { target i?86-*-* x86_64-*-* } } */

using T = unsigned char; // or ushort
using V [[gnu::vector_size(8)]] = T;
V f(V x) {
  return x >> 8 * sizeof(T);
}

/* { dg-final { scan-assembler {pxor\s+%xmm0,\s+%xmm0} { target { { i?86-*-*
x86_64-*-* } && lp64 } } } } */


w/o vlshr_optab,  vector operation will be lowered to scalar and be optimized
by pass_ccp4 in gimple. But w/ vlshr_optab, it's not optimized and left to the
backend, in the backend we don't optimize(just like what we did in
ix86_expand_vec_shift_qihi_constant).

As suggested by Richi, we may need to add a gimple simplification pattern to
handle this.

[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-06-24

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Sth as simple as

(simplify
 (rshift @0 INTEGER_CST@1)
 (if (TYPE_UNSIGNED (type)
      && compare_tree_int (@1, element_precision (type)) >= 0)
  { build_zero_cst (type); }))

does the trick.  Of course it's quite limited and we could handle
undefined left-shifts as well (even arithmetic ones).

[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Do we really want that for vectors with int or larger elements though?
Shouldn't it be done for char/short elements only?
For non-common targets where char and/or short could have the same precision as
int, maybe best would be to do it only for elements with precision smaller than
precision of integer_type_node.
The advantage of doing it only for the char/short cases is that we can catch it
later in warnings, ubsan etc.
We should verify what we diagnose with ubsan if we say char/short element
vector shifts are well defined.
Also, we should do that only if the shift count is smaller than precision of
integer_type_node, i.e. optimize vector char >> 8 to >> 31 but not >> 32 and
more.
For signed vectors >> should be optimized to shift by element precision - 1.

[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 24 Jun 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Do we really want that for vectors with int or larger elements though?
> Shouldn't it be done for char/short elements only?
> For non-common targets where char and/or short could have the same precision as
> int, maybe best would be to do it only for elements with precision smaller than
> precision of integer_type_node.
> The advantage of doing it only for the char/short cases is that we can catch it
> later in warnings, ubsan etc.
> We should verify what we diagnose with ubsan if we say char/short element
> vector shifts are well defined.
> Also, we should do that only if the shift count is smaller than precision of
> integer_type_node, i.e. optimize vector char >> 8 to >> 31 but not >> 32 and
> more.
> For signed vectors >> should be optimized to shift by element precision - 1.

But why restrict it?  CCP will optimize unsigned int >> 32 as well (but
yes, we diagnose that).

Unless there was this OpenCL compatibility thing which leaves large
shift semantics up to the target?

[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To make sure we diagnose it and catch it in ubsan and FE constant expression
folding.  The folding of the shift count into constant can happen almost any
time during the optimizations.
For ubsan and FE constant expression folding likely all that is needed is that
it is in match.pd GIMPLE only, because constexpr evaluation can use match.pd
folding and ubsan shifts are instrumented in the FEs, but for the diagnostics
not.

[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
*** Bug 101332 has been marked as a duplicate of this bug. ***