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.
