Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

[Lehua Ding]

Hi Robin,


> Hmm, ok so that has nothing to do with the rest of the patch but just
> happend to be the same test case.
> So we didn't schedule a vsetvl here because vmv1r doesn't require
> one but the simulation doesn't initialize vtype before the first vsetvl?
> If this is the only instance, I guess that's OK, but please add a comment
> as well.


Understood exactly right. There should be a harmonized solution to
this problem later. This is an interim solution for reduce unnecessary 
failures..


Best,
Lehua


-- Original --
From:   
 "Robin Dapp"   
 

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

[Robin Dapp via Gcc-patches]

Hi Lehua,

> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand

Thanks for checking, I know about those but have other FAILs.  Probably
due to a recent update or so, need to check.

> This is because running a testcase with spike+pk will result in an
> ILLEGAL INSTRUCTION error if the vtype registers are not initialized
> before executing vmv1r.v instruction. This case fails because of this reason,
> so explicitly execute vsetvl early. We are currently discussing with Kito to
> constrain this case in psABI and ask the execution environment(pk) to ensure
> that vtype is initialized, but not so fast. So when encountering a testcase 
> that
> fails because of this reason, I think use this way to fix it is ok.

Hmm, ok so that has nothing to do with the rest of the patch but just
happend to be the same test case.
So we didn't schedule a vsetvl here because vmv1r doesn't require
one but the simulation doesn't initialize vtype before the first vsetvl?
If this is the only instance, I guess that's OK, but please add a comment
as well.

OK with the two comments added.

Regards
 Robin

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

[Lehua Ding]

I see these failing testcases on trunk:


                === gcc: Unexpected 
fails for rv64gcv_zfh lp64d medany spike ===
FAIL: gcc.dg/pr42685.c (test for excess errors)
FAIL: gcc.dg/pr45105.c (test for excess errors)
XPASS: gcc.dg/unroll-7.c scan-rtl-dump-not loop2_unroll "Invalid sum"
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 18)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 21)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 31)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 32)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 35)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 45)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 55)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 63)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 66)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 68)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 69)
FAIL: gcc.dg/plugin/cpython-plugin-test-2.c 
-fplugin=./analyzer_cpython_plugin.so (test for excess errors)
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-16.c scan-tree-dump-times 
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-17.c scan-tree-dump-times 
optimized ".VEC_PERM" 2
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-18.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-18.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-18.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-18.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-19.c scan-assembler \\tvid\\.v
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-19.c scan-assemble

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

[Lehua Ding]

Hi Robin,


> unrelated but I'm seeing a lot of failing gather/scatter tests on
> master right now.


Are you talking about these FAILs like bellow? If so, If so it should be 
caused by a
recent commit from juzhe who is looking at it. If not, I didn't have 
these fails
in my local run.


  XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
  XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
  XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
  XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand



> Please add a small comment here which exact situation we're trying
> to prevent.


OK, will add a comment like bellow:


  /* Forbidden this case be fused because it change the value of a5.
   bb 1: vsetvl zero, no_zero_avl
 ...
 use a5
 ...
   bb 2: vsetvl a5, zero
 =>
   bb 1: vsetvl a5, zero
 ...
 use a5
 ...
   bb 2:
  */





> Why is this necessary or rather why is vtype uninitialized?  Is
> this the mentioned bug?  If so, why do we still need it with the
> vsetvl fix?


This is because running a testcase with spike+pk will result in an
ILLEGAL INSTRUCTION error if the vtype registers are not initialized
before executing vmv1r.v instruction. This case fails because of this 
reason,
so explicitly execute vsetvl early. We are currently discussing with Kito to
constrain this case in psABI and ask the execution environment(pk) to ensure
that vtype is initialized, but not so fast. So when encountering a testcase that
fails because of this reason, I think use this way to fix it is ok.


-- Original --
From:   
 "Robin Dapp"   
 

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

[Robin Dapp via Gcc-patches]

Hi Lehua,

unrelated but I'm seeing a lot of failing gather/scatter tests on
master right now.

> /* DIRTY -> DIRTY or VALID -> DIRTY.  */
> +   if (block_info.reaching_out.demand_p (DEMAND_NONZERO_AVL)
> +   && vlmax_avl_p (prop.get_avl ()))
> + continue;
> vector_insn_info new_info; 

Please add a small comment here which exact situation we're trying
to prevent.

> +asm volatile ("vsetivli x0, 0, e8, m1, ta, ma");

Why is this necessary or rather why is vtype uninitialized?  Is
this the mentioned bug?  If so, why do we still need it with the
vsetvl fix? 

Regards
 Robin