[Bug target/113607] New: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[Bug target/113607] New: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com]

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

            Bug ID: 113607
           Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Tested using r14-8438-g136a828754f

Testcase:
struct {
  signed b;
} c, d = {6};
short e, f;
int g[1000];
signed char h;
int i, j;
long k, l;

long m(long n, long o) {
  if (n < 1 && o == 0)
    return 0;
  return n;
}

static int p() {
  long q = 0;
  int a = 0;
  for (; e < 2; e += 1)
    g[e * 7 + 1] = 2637287069;
  for (; h <= 6; h += 1) {
    k = g[8] || f;
    l = m(g[f * 7 + 1], k);
    a = l;
    j = a < 0 || g[f * 7 + 1] < 0 || g[f * 7 + 1] >= 32 ? a : a << g[f * 7 +
1];
    if (j)
      ++q;
  }
  if (q)
    c = d;
  return i;
}

int main() {
  p();
  if (c.b == 0)
    return 0;
  else
    return 1;
}

Commands:
> /scratch/tc-testing/tc-jan-25-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -O3 -march=rv64gcv red.c -o user-config-o3.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true /scratch/tc-testing/tc-jan-25-trunk/build-rv64gcv/bin/qemu-riscv64 user-config-o3.out
> echo $?
1

> /scratch/tc-testing/tc-jan-25-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gcv red.c -o user-config-o2.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true /scratch/tc-testing/tc-jan-25-trunk/build-rv64gcv/bin/qemu-riscv64 user-config-o2.out
> echo $?
0

Found using fuzzer.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I can reproduce this issue.

Could you test it with this patch applied ?

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643934.html

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #2 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I can't reproduce this issue.

Could you test it with this patch applied ?

https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643934.html

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I tried trunk GCC to run your case with SPIKE, still didn't reproduce this
issue.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #4 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I cannot reproduce it either, tried with -ftree-vectorize as well as
-fno-vect-cost-model.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com]

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

--- Comment #5 from Patrick O'Neill <patrick at rivosinc dot com> ---
Hmm that's odd. I just reproduced with tip-of-tree GCC.

> /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -O3 -march=rv64gcv red.c -o user-config-o3.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/qemu-riscv64 user-config-o3.out
> echo $?
1

> /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gcv red.c -o user-config-o2.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/qemu-riscv64 user-config-o2.out
> echo $?
0

GCC: r14-8442-gd40b3c1e439
QEMU v8.1.2: 78385bc738108a9b5b20e639520dc60425ca2a5a 

Verbose compile output:
> /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -O3 -march=rv64gcv red.c -o user-config-o3.out -v
Using built-in specs.
COLLECT_GCC=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv
--with-sysroot=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot
--with-pkgversion=gd40b3c1e439 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2   
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2    -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240126 (experimental) (gd40b3c1e439)
COLLECT_GCC_OPTIONS='-O3' '-march=rv64gcv' '-o' 'user-config-o3.out' '-v'
'-mtune=rocket' '-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'user-config-o3.out-'

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/cc1
-quiet -v -imultilib . red.c -quiet -dumpdir user-config-o3.out- -dumpbase
red.c -dumpbase-ext .c -march=rv64gcv -mtune=rocket -mabi=lp64d
-misa-spec=20191213
-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-O3 -version -o /scratch/tmp/cc9XcIxi.s
GNU C17 (gd40b3c1e439) version 14.0.1 20240126 (experimental)
(riscv64-unknown-linux-gnu)
        compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/include

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/include-fixed

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/include
 /scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/usr/include
End of search list.
Compiler executable checksum: d731a6f03cb6c5b63837972018763b86
COLLECT_GCC_OPTIONS='-O3' '-march=rv64gcv' '-o' 'user-config-o3.out' '-v'
'-mtune=rocket' '-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'user-config-o3.out-'

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/bin/as
-v --traditional-format -march=rv64gcv
-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-mabi=lp64d -misa-spec=20191213 -o /scratch/tmp/cc7w3Ftf.o
/scratch/tmp/cc9XcIxi.s
GNU assembler version 2.41.50 (riscv64-unknown-linux-gnu) using BFD version
(GNU Binutils) 2.41.50.20231205
COMPILER_PATH=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/bin/
LIBRARY_PATH=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/lib/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/lib64/lp64d/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/usr/lib64/lp64d/:/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/lib/
COLLECT_GCC_OPTIONS='-O3' '-march=rv64gcv' '-o' 'user-config-o3.out' '-v'
'-mtune=rocket' '-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'user-config-o3.out.'

/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/collect2
-plugin
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/liblto_plugin.so
-plugin-opt=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
-plugin-opt=-fresolution=/scratch/tmp/cc30o9bR.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s
--sysroot=/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot
--eh-frame-hdr -melf64lriscv -dynamic-linker /lib/ld-linux-riscv64-lp64d.so.1
-o user-config-o3.out
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/usr/lib64/lp64d/crt1.o
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/crti.o
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/crtbegin.o
-L/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1
-L/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/lib
-L/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/lib64/lp64d
-L/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/usr/lib64/lp64d
-L/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/sysroot/lib
/scratch/tmp/cc7w3Ftf.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/crtend.o
/scratch/tc-testing/tc-jan-25-reconfirm/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/crtn.o
COLLECT_GCC_OPTIONS='-O3' '-march=rv64gcv' '-o' 'user-config-o3.out' '-v'
'-mtune=rocket' '-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'user-config-o3.out.'

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com]

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

--- Comment #6 from Patrick O'Neill <patrick at rivosinc dot com> ---
I think I may have messed up when copy/pasting the testcase. Please try this
testcase:

struct {
  signed b;
} c, d = {6};
short e, f;
int g[1000];
signed char h;
int i, j;
long k, l;

long m(long n, long o) {
  if (n < 1 && o == 0)
    return 0;
  return n;
}

static int p() {
  long q = 0;
  int a = 0;
  for (; e < 2; e += 1)
    g[e * 7 + 1] = 2637287069;
  for (; h < 1; h += 1) {
    k = g[8] || f;
    l = m(g[f * 7 + 1], k);
    a = l;
    j = a < 0 || g[f * 7 + 1] < 0 || g[f * 7 + 1] >= 32 ? a : a << g[f * 7 +
1];
    if (j)
      ++q;
  }
  if (q)
    c = d;
  return i;
}

int main() {
  p();
  if (c.b == 6)
    return 0;
  else
    return 1;
}

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #7 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Yep, that one fails for me now, thanks.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #8 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Ok. I can reproduce it too.

I am gonna work on fixing it.

Thanks.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Hi, Robin.

Could you try this case on latest ARM SVE ?

with -march=armv8-a+sve -O3 -fno-vect-cost-model.

I want to make sure first it is not an middle-end bug.

The RVV vectorized IR is same as ARM SVE.

Thanks.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #10 from Robin Dapp <rdapp at gcc dot gnu.org> ---
The compile farm machine I'm using doesn't have SVE.
Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and running
it returns 0 (i.e. ok).

pr113607.c:35:5: note: vectorized 3 loops in function.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #11 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Robin Dapp from comment #10)
> The compile farm machine I'm using doesn't have SVE.
> Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and
> running it returns 0 (i.e. ok).
> 
> pr113607.c:35:5: note: vectorized 3 loops in function.

Ok. Thanks. I just checked rvv-next which has similiar vectorized IR as
upstream RVV GCC.

But rvv-next return 0.

I will investigate what difference between them.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Let test tomorrow.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #13 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Ok. I found a regression between rvv-next and trunk.
I believe it is GCC-12 vs GCC-14:

rvv-next:
...
.L11:
        li      t1,31
        mv      a2,a1
        bleu    a7,t1,.L12
        bne     a6,zero,.L13
        li      a5,1
        subw    a5,a5,a3
        andi    a5,a5,0xff
        vsetvli a4,zero,e64,m1,ta,mu
        vmv.v.i v24,0
        vmv.v.x v27,a1
        vmv1r.v v26,v24
.L14:
        vsetvli a3,a5,e64,m1,tu,mu
        sub     a5,a5,a3
        vmsne.vi        v0,v27,0
        vmerge.vim      v25,v26,1,v0
        vadd.vv v24,v24,v25
        bne     a5,zero,.L14
        vsetvli a5,zero,e64,m1,ta,mu
        vmv.s.x v25,zero
        li      a3,0
        vredsum.vs      v25,v24,v25
        vmv.x.s a5,v25
        j       .L17
...

RVV trunk GCC:

.L8:
        lui     a0,%hi(h)
        lb      a4,%lo(h)(a0)
        bgt     a4,zero,.L37
        lui     a5,%hi(f)
        lh      t1,%lo(f)(a5)
        lui     a3,%hi(g)
        addi    a3,a3,%lo(g)
        lw      a6,4(a3)
        not     a1,a6
        slliw   a5,t1,3
        srai    a1,a1,63
        subw    a5,a5,t1
        lw      a7,32(a3)
        and     a1,a6,a1
        addiw   a2,a5,1
        bne     a7,zero,.L13
        bne     t1,zero,.L14
        mv      a5,a6
        blt     a6,zero,.L44
.L15:
        li      a3,31
        sext.w  a2,a5
        bleu    a6,a3,.L16
        li      a3,1
.L20:
        addiw   a5,a4,1
        bgt     a6,zero,.L45
        slliw   a4,a5,24
        sraiw   a4,a4,24
        bne     a4,a3,.L20
        li      a5,0
        li      a2,0
        j       .L19
.L37:
        lui     a5,%hi(c)
.L11:
        lw      a0,%lo(c)(a5)
        addi    a0,a0,-6
        snez    a0,a0
        ret

I don't think it will affect the correctness. But it's interesting
observations..

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc
-static t.c -O3 -fno-vect-cost-model -march=armv9-a+sve
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
0


This is with r14-8455-gc34ab549d88da1 .

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #15 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Hi, Robin.

I tried to disable vec_extract, then the case passed.

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 3b32369f68c..b61b886ef3d 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1386,7 +1386,7 @@
        (match_operand:V_VLS      1 "register_operand")
        (parallel
         [(match_operand          2 "nonmemory_operand")])))]
-  "TARGET_VECTOR"
+  "0"
 {
   /* Element extraction can be done by sliding down the requested element
      to index 0 and then v(f)mv.[xf].s it to a scalar register.  */


I am not so familiar with it (vec extract stuff), could you take a look at it ?

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #16 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Disabling vec_extract makes us operate on non-partial vectors, though so there
are a lot of differences in codegen.  I'm going to have a look.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #17 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Grasping for straws by blaming qemu ;)

At some point we do the vector shift

        vsll.vv v1,v2,v2,v0.t

but the mask v0 is all zeros:
gdb:
   b = {0 <repeats 16 times>}

According to the mask-undisturbed policy set before
        vsetvli zero,zero,e32,mf2,ta,mu

all elements should be unchanged.  I'm seeing an all-zeros result in v1,
though.
v1 is used as 'j', is zero and therefore 'q' is not incremented and we don't
assign c = d causing the wrong result.

Before the shift I see v2 in gdb as:
  w = {4294967295, 4294967295, 0, 0}
(That's also a bit dubious because we load 2 elements from 'g' of which only
one should be -1.  This doesn't change the end result, though.)

After the shift gdb shows v1 as:
   w = {0, 0, 0, 0},

when it should be w = {-1, -1, 0, 0}.

Does this make sense?

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #18 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Hehe no it doesn't make sense...  I wrongly read a v2 as a v1.  Please
disregard the last message.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #19 from Robin Dapp <rdapp at gcc dot gnu.org> ---
What seems odd to me is that in fre5 we simplify

  _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
... });
  vect_prephitmp_129.51_282 = _429;
  vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286,
vect_prephitmp_129.51_282, vect_cst__262>;

to

Applying pattern match.pd:9607, gimple-match-10.cc:3817
gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276,
vect_cst__262, vect_cst__262, { 0, ... });

so fold

vec_cond (mask209, prephitmp129, vect_cst262)
with prephitmp129 = cond_shl (mask205, vect_cst262, vect_cst262, 0)

into
cond_shl = (mask205, vect_cst262, vect_cst262, 0)?

That doesn't look valid to me because the vec_cond's else value (vect_cst262)
gets lost.  Wouldn't such a simplification have a conditional else value?
Like !mask1 ? else1 : else2 instead of else2 unconditionally?

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[juzhe.zhong at rivai dot ai]

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

--- Comment #20 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
> 
>   _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
>   vect_prephitmp_129.51_282 = _429;
>   vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286,
> vect_prephitmp_129.51_282, vect_cst__262>;
> 
> to
> 
> Applying pattern match.pd:9607, gimple-match-10.cc:3817
> gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276,
> vect_cst__262, vect_cst__262, { 0, ... });
> 
> so fold
> 
> vec_cond (mask209, prephitmp129, vect_cst262)
> with prephitmp129 = cond_shl (mask205, vect_cst262, vect_cst262, 0)
> 
> into
> cond_shl = (mask205, vect_cst262, vect_cst262, 0)?
> 
> That doesn't look valid to me because the vec_cond's else value
> (vect_cst262) gets lost.  Wouldn't such a simplification have a conditional
> else value?
> Like !mask1 ? else1 : else2 instead of else2 unconditionally?

Does ARM SVE have the same issue too ? Since I think we should be using same
folding optimization as ARM SVE.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #20)
> Does ARM SVE have the same issue too ? Since I think we should be using same
> folding optimization as ARM SVE.

I could not reproduce it with SVE, see comment 14 .

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #19)
> What seems odd to me is that in fre5 we simplify
> 
>   _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
>   vect_prephitmp_129.51_282 = _429;
>   vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286,
> vect_prephitmp_129.51_282, vect_cst__262>;


this is:

_429 = mask_patt_205.47_276[i] ? vect_cst__262[i] : (vect_cst__262 <<
{0,..})[i];
vect_iftmp.55_287 = mask_patt_209.54_286[i] ? _429 [i] : vect_cst__262[i]

Which should have folded into:
tmp_ = mask_patt_205.47_276 | ~mask_patt_209.54_286;
_429 = .COND_SHL (tmp_, vect_cst__262, vect_cst__262, { 0, ... });

What is the definition of mask_patt_209.54_286 and mask_patt_205.47_276?
is `mask_patt_209.54_286 = ~mask_patt_205.47_276` ?

If so then this is a valid transformation I think.

[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[rdapp at gcc dot gnu.org]

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

--- Comment #23 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> this is:
> 
> _429 = mask_patt_205.47_276[i] ? vect_cst__262[i] : (vect_cst__262 <<
> {0,..})[i];
> vect_iftmp.55_287 = mask_patt_209.54_286[i] ? _429 [i] : vect_cst__262[i]

But isn't it rather
_429 = mask_patt_205.47_276[i] ? (vect_cst__262[i] << vect_cst__262[i]) :
{0,..})[i]?

The else should be the last operand, shouldn't it?

On aarch64 we don't seem to emit a COND_SHL therefore this particular situation
does not occur.

However the simplification was introduced for aarch64:

(for cond_op (COND_BINARY)
 (simplify
  (vec_cond @0
   (cond_op:s @1 @2 @3 @4) @3)
  (cond_op (bit_and @1 @0) @2 @3 @4)))

It is supposed to simplify (in gcc.target/aarch64/sve/pre_cond_share_1.c)

  _256 = .COND_MUL (mask__108.48_193, vect_iftmp.45_187, vect_cst__190, { 0.0,
... });
  vect_prephitmp_151.50_197 = VEC_COND_EXPR <mask__101.46_189, _256,
vect_cst__190>;

into COND_MUL (mask108 & mask101, vect_iftmp.45_187, vect_cst__190, { 0.0, ...
});

But that doesn't look valid to me either.  No matter what _256 is, the result
for !mask101 should be vect_cst__190 and not 0.0.

[Bug middle-end/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:8123f3ca3fd891034a8366518e756f161c4ff40d

commit r14-8668-g8123f3ca3fd891034a8366518e756f161c4ff40d
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Tue Jan 30 18:39:08 2024 +0100

    match: Fix vcond into conditional op folding [PR113607].

    In PR113607 we see an invalid fold of

      _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, {
0, ... });
      vect_prephitmp_129.51_282 = _429;
      vect_iftmp.55_287 = VEC_COND_EXPR <mask_patt_209.54_286,
vect_prephitmp_129.51_282, vect_cst__262>;

    to

      Applying pattern match.pd:9607, gimple-match-10.cc:3817
      gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276,
vect_cst__262, vect_cst__262, { 0, ... });

    where we essentially use COND_SHL's else instead of VEC_COND_EXPR's.

    This patch adjusts the corresponding match.pd pattern and makes it only
    match when the else values are the same.

    That, however, causes the exact test case for which this pattern was
    introduced for to fail.  Therefore XFAIL it for now.

    gcc/ChangeLog:

            PR middle-end/113607

            * match.pd: Make sure else values match when folding a
            vec_cond into a conditional operation.

    gcc/testsuite/ChangeLog:

            * gcc.target/aarch64/sve/pre_cond_share_1.c: XFAIL.
            * gcc.target/riscv/rvv/autovec/pr113607-run.c: New test.
            * gcc.target/riscv/rvv/autovec/pr113607.c: New test.

[Bug middle-end/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com]

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

Patrick O'Neill <patrick at rivosinc dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #25 from Patrick O'Neill <patrick at rivosinc dot com> ---
Confirmed fixed. Thanks!