[Bug target/113087] New: [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[Bug target/113087] New: [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

            Bug ID: 113087
           Summary: [14] RISC-V rv64gcv vector: Runtime mismatch with
                    rv64gc
           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: ---

Sorry for the non-descriptive issue title - I'm not sure what's going on here.

Testcase:
int(e)(int g, int h) { return h > 0x10 || g > 0xFFFFFFFF >> h ? g : g << h; }
struct i {
  int j;
  int l : 1;
};
struct m {
  char k;
  int n;
};
char o;
char p;
short s;
int q;
struct m r;
int v;
int t;
short z;
long ac;
int ad;
int ae;

static void ai(struct i bf) {
  for (; v; v++)
    r.k = 0;
  do
    ac ^= bf.j;
  while (bf.j < 0);
  s = 0;
  if (bf.l)
    q |= 0x800;
}

int main() {
  struct i aw = {0xE00, 1};
  o = 4;
  s = p;
  ai(aw);
  t = 1;
  ++p;
  for (; t <= 7; t++) {
    ad &= 1;
    (o &= 1 - e(0x40000012, ++ae)) & (z |= 1);
  }
  for (; r.n;)
    ;
  if (o != 4)
    return 1;
}

Analysis:
o = 4;
... Ignore first 7 iterations of loop, only consider last iter (ae = 7)
o &= 1 - e(0x40000012, ++ae)
expanded:
o = 4 & (1 - e(0x40000012, 8))
expanded:
o = 4 & (1 - (8 > 0x10 || 0x40000012 > 0xFFFFFFFF >> 8 ? 0x40000012 :
0x40000012 << 8))
partially evaluated:
o = 4 & (1 - (false || 0x40000012 > 0xFFFFFF ? 0x40000012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (false || true ? 0x40000012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (true ? 0x40000012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (0x40000012))
partially evaluated:
o = 4 & (0xBFFFFFEF)
evaluated:
o = 4

Commands:
> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O3 red.c -o rv64gcv.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout --verbose -k 0.1 1 /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gcv.out
> echo $?
1

> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc -march=rv64gc -mabi=lp64d -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout --verbose -k 0.1 1 /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
> echo $?
0

Behavior found using gcc hash: r14-6716-g1502d724df8

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Is this coming from SPEC 527 or 549 ?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #2 from Patrick O'Neill <patrick at rivosinc dot com> ---
No, this is from a random generator but the 527/549 issues could be related?
I haven't reduced spec fails.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #3 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #2)
> No, this is from a random generator but the 527/549 issues could be related?
> I haven't reduced spec fails.

I can't reproduce spec fails. We have tested it on both QEMU and K230 with
-march=rv64gcv_zvl256b, all passed.

Could you reduce spec fails ?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #4 from Patrick O'Neill <patrick at rivosinc dot com> ---
I can attempt to reduce them however running an iteration of 549 takes multiple
hours so it might be challenging using my current setup (creduce).
Hopefully the random generator stumbles across the same issue and it can get
fixed that way since it's worked for other spec fails previously.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #4)
> I can attempt to reduce them however running an iteration of 549 takes
> multiple hours so it might be challenging using my current setup (creduce).
> Hopefully the random generator stumbles across the same issue and it can get
> fixed that way since it's worked for other spec fails previously.

I confirmed it is vsetvl bugs. But I wonder whether you have open source the
random generator ?

If yes, may be we can dedicate some resources to run random tests too.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #6 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to JuzheZhong from comment #5)
> ...
> I confirmed it is vsetvl bugs. But I wonder whether you have open source the
> random generator ?
> 
> If yes, may be we can dedicate some resources to run random tests too.

I use csmith as the random generator and try to fuzz targets that don't have
any execution fails/ICEs (currently just rv64gcv/rv64gcv_zvl256b).
https://github.com/csmith-project/csmith

I was planning on getting the fuzzer and a random config builder running on
spare precommit compute but haven't set it up yet. I'll clean up/put the shell
scripts I use for csmith here tomorrow:
https://github.com/patrick-rivos/gcc-fuzz-ci

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pan Li <panli@gcc.gnu.org>:

https://gcc.gnu.org/g:d82bb518fa372cc30cc3352e0a124d0bd6deb36f

commit r14-6760-gd82bb518fa372cc30cc3352e0a124d0bd6deb36f
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Wed Dec 20 14:50:11 2023 +0800

    RISC-V: Fix bug of VSETVL fusion

    This patch fixes bugs in the fusion of this following case:

    li a5,-1
    vmv.s.x v0,a5 -> demand any non-zero AVL
    vsetvli a5, ...

    Incorrect fusion after VSETVL PASS:

    li a5,-1
    vsetvli a5...
    vmv.s.x v0, a5 --> a5 is modified as incorrect value.

    We disallow this incorrect fusion above.

    Full coverage testing of RV64 and RV32 no regression.

            PR target/113087

    gcc/ChangeLog:

            * config/riscv/riscv-vsetvl.cc: Disallow fusion when VL
modification pollutes non AVL use.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/autovec/pr113087-1.c: New test.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pan Li <panli@gcc.gnu.org>:

https://gcc.gnu.org/g:008b80e42eb7cb55c6a2ef55728241b8733dfd17

commit r14-6761-g008b80e42eb7cb55c6a2ef55728241b8733dfd17
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Wed Dec 20 14:55:26 2023 +0800

    RISC-V: Optimize SELECT_VL codegen when length is known as smaller than VF

    While trying to fix bugs of PR113097, notice this following situation we
    generate redundant vsetvli

    _255 = SELECT_VL (3, POLY_INT_CST [4, 4]);
    COND_LEN (..., _255)

    Before this patch:

    vsetivli a5, 3...
    ...
    vadd.vv (use a5)

    After this patch:

    ...
    vadd.vv (use AVL = 3)

    The reason we can do this is because known_ge (3, [4,4]) is true.
    It's safe to apply such optimization

    Tested on both RV32 and RV64 full coverage testing, no regression.

            PR target/113087

    gcc/ChangeLog:

            * config/riscv/riscv-v.cc (expand_select_vl): Optimize SELECT_VL.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/autovec/pr113087-2.c: New test.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
It's fixed on the trunk.

I wonder whether it can fix the issues that you (RIVOS) fail to run SPEC 527
and. 549

We have fixed several issues recently, could you use the latest trunk GCC to
run SPEC today ?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

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

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

--- Comment #10 from Patrick O'Neill <patrick at rivosinc dot com> ---
I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. I'll
let you know the results when they finish.

Thanks for the quick fix on this bug!

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #11 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Patrick O'Neill from comment #10)
> I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> I'll let you know the results when they finish.

My terminal crashed - so these are partial results:
zvl256: 3 runtime failures
531.deepsjeng
???
???

zvl128: 1 runtime failure
527.cam4_r

If I had to guess I would say the 2 ??? fails are the existing 521/549.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #12 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #11)
> (In reply to Patrick O'Neill from comment #10)
> > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> > I'll let you know the results when they finish.
> 
> My terminal crashed - so these are partial results:
> zvl256: 3 runtime failures
> 531.deepsjeng
> ???
> ???
> 
> zvl128: 1 runtime failure
> 527.cam4_r
> 
> If I had to guess I would say the 2 ??? fails are the existing 521/549.

You mean those 2 cases are still failing?
Do you have any ideas to locate those FAIL and extract them as a simple case?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[vineetg at gcc dot gnu.org]

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

Vineet Gupta <vineetg at gcc dot gnu.org> changed:

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

--- Comment #13 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #12)
> (In reply to Patrick O'Neill from comment #11)
> > (In reply to Patrick O'Neill from comment #10)
> > > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> > > I'll let you know the results when they finish.
> > 
> > My terminal crashed - so these are partial results:
> > zvl256: 3 runtime failures
> > 531.deepsjeng
> > ???
> > ???
> > 
> > zvl128: 1 runtime failure
> > 527.cam4_r
> > 
> > If I had to guess I would say the 2 ??? fails are the existing 521/549.
> 
> You mean those 2 cases are still failing?
> Do you have any ideas to locate those FAIL and extract them as a simple case?

> zvl128 / no vl: 1 runtime failure
> 527.cam4_r

Yes this still remains. It is hard to debug (for me at least) as this is
fortran.

However this goes away if simple_vsetvl is used (with -Ofast for rest of
buiild) - using [1]

[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641342.html

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[vineetg at gcc dot gnu.org]

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

--- Comment #14 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Vineet Gupta from comment #13)
> (In reply to JuzheZhong from comment #12)
> > (In reply to Patrick O'Neill from comment #11)
> > > (In reply to Patrick O'Neill from comment #10)
> > > > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> > > > I'll let you know the results when they finish.
> > > 
> > > My terminal crashed - so these are partial results:
> > > zvl256: 3 runtime failures
> > > 531.deepsjeng
> > > ???
> > > ???

At least 549.fotonik3d runtime failure with vl256 remains even with
simple_vsetvl.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #15 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Currently, we don't have much run FAIL and ICE left in full coverage testing.

I suspect it is very corner case in SPEC.

You don't have to debug it. Just need to give me a preprocessed source file.

Like this:

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

You can see google highway folks attachment is very big but I still can fix the
issue as long as you can give me some sources that I can reproduce the issues.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[vineetg at gcc dot gnu.org]

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

--- Comment #16 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #15)
> Currently, we don't have much run FAIL and ICE left in full coverage testing.
> 
> I suspect it is very corner case in SPEC.
> 
> You don't have to debug it. Just need to give me a preprocessed source file.
> 
> Like this:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560
> 
> You can see google highway folks attachment is very big but I still can fix
> the issue as long as you can give me some sources that I can reproduce the
> issues.

As I mentioned already these are runtime failure mismatches, so we don't know
where the issue is and thus no reduced test case. 

FWIW I could/would have debugged gcc code it if I had a reduced test.

So we need to dig down into guts of the benchmark and see where the output is
generated, checkpoint and so on so forth etc.

The other approach is to try "defeature" autovec and see if can point to broad
areas (in backend/middle-end) where the issue could be.
e.g.
  - simple vs. lazy vsetvl
  - disabling reductions etc.

BTW I'm surprised you are not seeing these as there is nothing rivos specific
here. Are you running the full SPEC suite, including Fortran / Float workloads.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #17 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
PLCT told me they passed with zvl256b.

I always run SPEC with FIXED-VLMAX since we always care about peak performance
on our board.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[vineetg at gcc dot gnu.org]

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

--- Comment #18 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #17)
> PLCT told me they passed with zvl256b.
> 
> I always run SPEC with FIXED-VLMAX since we always care about peak
> performance
> on our board.

Sure we all have our preferred peak performance configs. But the compiler needs
to work for all vendors' configs. So as a test, can you try a scalable build
run at your end to at least see if you can see those issues ?

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #19 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Vineet Gupta from comment #18)
> (In reply to JuzheZhong from comment #17)
> > PLCT told me they passed with zvl256b.
> > 
> > I always run SPEC with FIXED-VLMAX since we always care about peak
> > performance
> > on our board.
> 
> Sure we all have our preferred peak performance configs. But the compiler
> needs to work for all vendors' configs. So as a test, can you try a scalable
> build run at your end to at least see if you can see those issues ?

I am not able to build and test SPEC since I don't have QEMU and SPEC
environment.

I should ask my colleague to do that but they are quite busy with company's
things and frankly I can't pull more resource on open source work from my
company.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #20 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I am not able to build and test SPEC since I don't have QEMU and SPEC
environment.

I should ask my colleague to do that but they are quite busy with company's
things and frankly I can't pull more resource on open source work from my
company.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #21 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Btw, I saw there are 2 more FAILs:

FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s114.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s114.c execution test

on -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=dynamic.

I am not sure whether they are same issue as SPEC issue on your side.

I am going to fix them to see whether we are "lucky".

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

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

--- Comment #22 from palmer at gcc dot gnu.org ---
(In reply to JuzheZhong from comment #19)
> (In reply to Vineet Gupta from comment #18)
> > (In reply to JuzheZhong from comment #17)
> > > PLCT told me they passed with zvl256b.
> > > 
> > > I always run SPEC with FIXED-VLMAX since we always care about peak
> > > performance
> > > on our board.
> > 
> > Sure we all have our preferred peak performance configs. But the compiler
> > needs to work for all vendors' configs. So as a test, can you try a scalable
> > build run at your end to at least see if you can see those issues ?
> 
> I am not able to build and test SPEC since I don't have QEMU and SPEC
> environment.

Sorry, I'm kind of confused here: you're saying you can't build/test SPEC, but
then above saying you run SPEC.

> I should ask my colleague to do that but they are quite busy with company's
> things and frankly I can't pull more resource on open source work from my
> company.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #23 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to palmer from comment #22)
> (In reply to JuzheZhong from comment #19)
> > (In reply to Vineet Gupta from comment #18)
> > > (In reply to JuzheZhong from comment #17)
> > > > PLCT told me they passed with zvl256b.
> > > > 
> > > > I always run SPEC with FIXED-VLMAX since we always care about peak
> > > > performance
> > > > on our board.
> > > 
> > > Sure we all have our preferred peak performance configs. But the compiler
> > > needs to work for all vendors' configs. So as a test, can you try a scalable
> > > build run at your end to at least see if you can see those issues ?
> > 
> > I am not able to build and test SPEC since I don't have QEMU and SPEC
> > environment.
> 
> Sorry, I'm kind of confused here: you're saying you can't build/test SPEC,
> but then above saying you run SPEC.
> 
> > I should ask my colleague to do that but they are quite busy with company's
> > things and frankly I can't pull more resource on open source work from my
> > company.

I am sorry that my typo make you confused. I must say "we" instead of "I" :).

"We" is PLCT lab, my colleague, and Li Pan.

I just notice my careless writing, sometimes say "I", sometimes say "we".

Since I always ask some body do things I want to do.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #24 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
CC jiawei who run SPEC for me. Maybe you can help him to reproduce such issue
then I can debug it from his feedback.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[jiawei at iscas dot ac.cn]

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

--- Comment #25 from jiawei <jiawei at iscas dot ac.cn> ---
I had run SPEC2017-v1.1.9 with rv64gcv_zvl256b, it passed the compile and run
on base and validate cases, used qemu 8.1.0.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #26 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
CC Li Pan who may also reproduce the bugs for me.

Plz give us more details how to reproduce the bugs since we don't see any bugs
when build and run SPEC.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #27 from Patrick O'Neill <patrick at rivosinc dot com> ---
Linking the discussion/plan here since more interested people are CCd here.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
zvl128b (All runtime fails):
527.cam4 (Runtime)
531.deepsjeng (Runtime)
521.wrf (Runtime)
523.xalancbmk (Runtime)

zvl256b:
507.cactuBSSN (Runtime)
521.wrf (Build)
527.cam4 (Runtime)
531.deepsjeng (Runtime)
549.fotonik3d (Runtime)

With that info I think the next steps are:
1. Triage the zvl256b 521.wrf build failure
2. Bisect the newly-failing testcases
3. Finish triaging the remaining testcases the fuzzer found
4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the
fastest build+runtime)
5. Attempt to manually reduce other fails.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #28 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #27)
> Linking the discussion/plan here since more interested people are CCd here.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
> zvl128b (All runtime fails):
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
> 521.wrf (Runtime)
> 523.xalancbmk (Runtime)
> 
> zvl256b:
> 507.cactuBSSN (Runtime)
> 521.wrf (Build)
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
> 549.fotonik3d (Runtime)
> 
> With that info I think the next steps are:
> 1. Triage the zvl256b 521.wrf build failure
> 2. Bisect the newly-failing testcases
> 3. Finish triaging the remaining testcases the fuzzer found
> 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the
> fastest build+runtime)
> 5. Attempt to manually reduce other fails.

Plz reduce cam4 for zvl128b first. No need to care about build fail of wrf.
We already know the reason, it's middle-end issue which takes some time.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[pan2.li at intel dot com]

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

--- Comment #29 from Li Pan <pan2.li at intel dot com> ---
(In reply to Patrick O'Neill from comment #27)
> Linking the discussion/plan here since more interested people are CCd here.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
> zvl128b (All runtime fails):
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
> 521.wrf (Runtime)
> 523.xalancbmk (Runtime)
> 
> zvl256b:
> 507.cactuBSSN (Runtime)
> 521.wrf (Build)
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
> 549.fotonik3d (Runtime)
> 
> With that info I think the next steps are:
> 1. Triage the zvl256b 521.wrf build failure
> 2. Bisect the newly-failing testcases
> 3. Finish triaging the remaining testcases the fuzzer found
> 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the
> fastest build+runtime)
> 5. Attempt to manually reduce other fails.

Hi Patrick,

Thanks a lot for the summary. Could you please help to share some more
information about the spec2017 for above data? Like data set (test, train, or
ref), the enviornment (qemu, spike, or hardware) as well as the spec config
file. Just would like to make sure we are on the same page for the failures and
reproducible from others.

Thanks again. Pan

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #30 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Li Pan from comment #29)
> Thanks a lot for the summary. Could you please help to share some more
> information about the spec2017 for above data? Like data set (test, train,
> or ref), the enviornment (qemu, spike, or hardware) as well as the spec
> config file. Just would like to make sure we are on the same page for the
> failures and reproducible from others.

Hi Pan,

We use nix to build/run spec so it's a bit opaque to me but I've extracted out:
ref data set
qemu
flags:
"-Ofast"
"-mtune=generic-ooo"
"-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa"
"-fno-lto"
"-ftree-vectorize"
"--param=riscv-autovec-preference=scalable"

There are other flags that are are injected by the nix harness and I'm in the
process of pulling them out. With these flags you should at least see the cam4
failure. Vineet is looking at the cam4 failure and is planning to open a
bugzilla with details.

Thanks,
Patrick

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #31 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #30)
> (In reply to Li Pan from comment #29)
> > Thanks a lot for the summary. Could you please help to share some more
> > information about the spec2017 for above data? Like data set (test, train,
> > or ref), the enviornment (qemu, spike, or hardware) as well as the spec
> > config file. Just would like to make sure we are on the same page for the
> > failures and reproducible from others.
> 
> Hi Pan,
> 
> We use nix to build/run spec so it's a bit opaque to me but I've extracted
> out:
> ref data set
> qemu
> flags:
> "-Ofast"
> "-mtune=generic-ooo"
> "-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa"
> "-fno-lto"
> "-ftree-vectorize"
> "--param=riscv-autovec-preference=scalable"
> 
> There are other flags that are are injected by the nix harness and I'm in
> the process of pulling them out. With these flags you should at least see
> the cam4 failure. Vineet is looking at the cam4 failure and is planning to
> open a bugzilla with details.
> 
> Thanks,
> Patrick

You are using -Ofast which will have precision issue on floating-point.

You can reference it:

https://godbolt.org/z/zzG8xbx95

O3 result: 50002896.000000
Ofast result: 50005000.000000

They are different and not correctness issue.

GCC is same behavior as LLVM.

More details:
https://github.com/llvm/llvm-project/issues/77044

So, to elide the potential floating-point precision confusion,
I suggest you first use -O3 -ftrapping-math to test SPEC.

Otherwise, it's really hard to locate the real issue.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #32 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to JuzheZhong from comment #31)
> You are using -Ofast which will have precision issue on floating-point.
> 
> You can reference it:
> 
> https://godbolt.org/z/zzG8xbx95
> 
> O3 result: 50002896.000000
> Ofast result: 50005000.000000
> 
> They are different and not correctness issue.
> 
> GCC is same behavior as LLVM.
> 
> More details:
> https://github.com/llvm/llvm-project/issues/77044
> 
> So, to elide the potential floating-point precision confusion,
> I suggest you first use -O3 -ftrapping-math to test SPEC.
> 
> Otherwise, it's really hard to locate the real issue.

The cam4 failure still appears with:
"-O3"
"-ftrapping-math"
"-mtune=generic-ooo"
"-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa"
"-fno-lto"
"-ftree-vectorize"
"--param=riscv-autovec-preference=scalable"

I'll keep digging through the harness and finding the remaining flags.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[vineetg at gcc dot gnu.org]

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

Vineet Gupta <vineetg at gcc dot gnu.org> changed:

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

--- Comment #33 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
cam4 failure is a bug in vsetvl pass which I'm debugging atm.
An erroneous vsetvl insn is getting generated, clobbering a live register used
subsequently in a V insn.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #34 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #32)
> (In reply to JuzheZhong from comment #31)
> > You are using -Ofast which will have precision issue on floating-point.
> > 
> > You can reference it:
> > 
> > https://godbolt.org/z/zzG8xbx95
> > 
> > O3 result: 50002896.000000
> > Ofast result: 50005000.000000
> > 
> > They are different and not correctness issue.
> > 
> > GCC is same behavior as LLVM.
> > 
> > More details:
> > https://github.com/llvm/llvm-project/issues/77044
> > 
> > So, to elide the potential floating-point precision confusion,
> > I suggest you first use -O3 -ftrapping-math to test SPEC.
> > 
> > Otherwise, it's really hard to locate the real issue.
> 
> The cam4 failure still appears with:
> "-O3"
> "-ftrapping-math"
> "-mtune=generic-ooo"
> "-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa"
> "-fno-lto"
> "-ftree-vectorize"
> "--param=riscv-autovec-preference=scalable"
> 
> I'll keep digging through the harness and finding the remaining flags.

CAM4 is likely VSETVLI bug that Robin told me.

I mean the other failures.
Could you trigger a full run of SPEC with -O3 -ftrapping-math ?

To see how many bugs in SPEC actually.

I think we don't need to care about the failures which caused by floating-point
precision.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #35 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Vineet Gupta from comment #33)
> cam4 failure is a bug in vsetvl pass which I'm debugging atm.
> An erroneous vsetvl insn is getting generated, clobbering a live register
> used subsequently in a V insn.

Could you give me the peephole of assembler sequence ?

Maybe I can try to reproduce it with RVV intrinsics then I can fix it.

I think I can fix it quickly if it is vsetvl bugs.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

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

I just fixed a bug that will cause VSETVL PASS and AVL prop PASS bug.

Could you trigger a full run of SPEC with -O3 -ftrapping-math again ?

Thanks.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[rdapp at gcc dot gnu.org]

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

--- Comment #37 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
> zvl128b (All runtime fails):
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
> 521.wrf (Runtime)
> 523.xalancbmk (Runtime)

I tried reproducing the xalanc fail first but with the current trunk I don't
see a runtime fail.  Going to try deepsjeng next.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[rdapp at gcc dot gnu.org]

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

--- Comment #38 from Robin Dapp <rdapp at gcc dot gnu.org> ---
deepsjeng also looks ok here.

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #39 from Patrick O'Neill <patrick at rivosinc dot com> ---
FYI I ran spec2017 last night and got:

zvl128b:
no fails!

zvl256b:
549.fotonik3d (runtime) - pr113570

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #40 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Patrick O'Neill from comment #39)
> FYI I ran spec2017 last night and got:
> 
> zvl128b:
> no fails!
> 
> zvl256b:
> 549.fotonik3d (runtime) - pr113570

GCC hash:
a1b2953924c451ce90a3fdce6841b63bf05f335f

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

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

Could you trigger test again base on latest trunk GCC?

We have recent memory-hog fix patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321

I want to make sure it doesn't cause a regression on SPEC.

I have tested it with full coverage GCC testsuite, no regression.

But I want to know about SPEC 2017

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #42 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to JuzheZhong from comment #41)
> Hi, Patrick.
> 
> Could you trigger test again base on latest trunk GCC?
> 
> We have recent memory-hog fix patch:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321
> 
> I want to make sure it doesn't cause a regression on SPEC.
> 
> I have tested it with full coverage GCC testsuite, no regression.
> 
> But I want to know about SPEC 2017

I kicked off a run roughly 10 hours ago with your memory-hog fix patch applied
to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results here when
the runs complete. Thanks!

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com]

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

--- Comment #43 from Patrick O'Neill <patrick at rivosinc dot com> ---
(In reply to Patrick O'Neill from comment #42)
> I kicked off a run roughly 10 hours ago with your memory-hog fix patch
> applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results
> here when the runs complete. Thanks!

No new failures!

zvl128b:
no fails!

zvl256b:
549.fotonik3d (runtime) - pr113570 (looks like this fail is since I used
-Ofast)

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[juzhe.zhong at rivai dot ai]

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

--- Comment #44 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Patrick O'Neill from comment #43)
> (In reply to Patrick O'Neill from comment #42)
> > I kicked off a run roughly 10 hours ago with your memory-hog fix patch
> > applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results
> > here when the runs complete. Thanks!
> 
> No new failures!
> 
> zvl128b:
> no fails!
> 
> zvl256b:
> 549.fotonik3d (runtime) - pr113570 (looks like this fail is since I used
> -Ofast)

Thanks. Could you trigger full coverage testing of SPEC with these following
combination compile option:


-march=rv64gcv --param=riscv-autovec-lmul=m2
-march=rv64gcv --param=riscv-autovec-lmul=m4
-march=rv64gcv --param=riscv-autovec-lmul=m8
-march=rv64gcv --param=riscv-autovec-lmul=dynamic

-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m2
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m4
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m8
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=dynamic

-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m2
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m4
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m8
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=dynamic

-march=rv64gcv --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

-march=rv64gcv_zvl256b --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

-march=rv64gcv_zvl512b --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

I believe they can be separate tasks assigned muitl-cores or muti-thread run
simultaneously.