]> git.ipfire.org Git - thirdparty/gcc.git/commit
RISC-V: Disallow negative step for interleaving [PR117682]
authorRobin Dapp <rdapp.gcc@gmail.com>
Tue, 14 Jan 2025 00:09:35 +0000 (17:09 -0700)
committerJeff Law <jlaw@ventanamicro.com>
Tue, 14 Jan 2025 00:10:02 +0000 (17:10 -0700)
commit7b815107f403c526b7e201ca00494f06d1c20768
tree53c3e37fcb3d036a93d5ca0d3d018128b73824f7
parent1f6453684696b1c18899cbbecd4bd5ed4ae22476
RISC-V: Disallow negative step for interleaving [PR117682]

Hi,

in PR117682 we build an interleaving pattern

  { 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
    17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
    33, 233, 241, 57, 193, 137, 145, 217, 97, 41,
    49, 121 };

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.
gcc/config/riscv/riscv-v.cc
gcc/testsuite/gcc.target/riscv/rvv/autovec/pr117682.c [new file with mode: 0644]