with negative step expecting wraparound semantics due to -fwrapv.
For building interleaved patterns we have an optimization that
does e.g.
{1, 209, ...} = { 1, 0, 209, 0, ...}
and
{201, 25, ...} >> 8 = { 0, 201, 0, 25, ...}
and IORs those.
The optimization only works if the lowpart bits are zero. When
overflowing e.g. with a negative step we cannot guarantee this.
This patch makes us fall back to the generic merge handling for negative
steps.
I'm not 100% certain we're good even for positive steps. If the
step or the vector length is large enough we'd still overflow and
have non-zero lower bits. I haven't seen this happen during my
testing, though and the patch doesn't make things worse, so...
Regtested on rv64gcv_zvl512b. Let's see what the CI says.
Regards
Robin
PR target/117682
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Fall back to
merging if either step is negative.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117682.c: New test.