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"                       
                                                             
<gcc-patches@gcc.gnu.org&gt;;
Date:&nbsp;Thu, Aug 17, 2023 08:15 PM
To:&nbsp;"Lehua 
Ding"<lehua.d...@rivai.ai&gt;;"gcc-patches"<gcc-patches@gcc.gnu.org&gt;;
Cc:&nbsp;"rdapp.gcc"<rdapp....@gmail.com&gt;;"juzhe.zhong"<juzhe.zh...@rivai.ai&gt;;"kito.cheng"<kito.ch...@gmail.com&gt;;"palmer"<pal...@rivosinc.com&gt;;"jeffreyalaw"<jeffreya...@gmail.com&gt;;
Subject:&nbsp;Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to 
DEMAND_NONZERO_AVL vsetvl



Hi Lehua,

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

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

&gt; This is because running a testcase with spike+pk will result in an
&gt; ILLEGAL INSTRUCTION error if the vtype registers are not initialized
&gt; before executing vmv1r.v instruction.&nbsp;This case fails because of this 
reason,
&gt; so explicitly execute vsetvl early. We are currently discussing with Kito 
to
&gt; constrain this case in psABI and ask the execution environment(pk) to 
ensure
&gt; that vtype is initialized, but not so fast. So when encountering a 
testcase that
&gt; 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