[v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

Message ID 20240419142901.1585821-1-pan2.li@intel.com
State Superseded
Headers
Series [v1] RISC-V: Revert RVV wv instructions overlap and xfail tests |

Checks

Context Check Description
rivoscibot/toolchain-ci-rivos-apply-patch success Patch applied
rivoscibot/toolchain-ci-rivos-lint warning Lint failed
linaro-tcwg-bot/tcwg_gcc_build--master-arm success Testing passed
rivoscibot/toolchain-ci-rivos-build--newlib-rv64gcv-lp64d-multilib success Build passed
rivoscibot/toolchain-ci-rivos-build--linux-rv64gcv-lp64d-multilib success Build passed
rivoscibot/toolchain-ci-rivos-build--newlib-rv64gc-lp64d-multilib success Build passed
linaro-tcwg-bot/tcwg_gcc_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 success Testing passed
rivoscibot/toolchain-ci-rivos-build--linux-rv64gc_zba_zbb_zbc_zbs-lp64d-non-multilib success Build passed
rivoscibot/toolchain-ci-rivos-build--linux-rv32gc_zba_zbb_zbc_zbs-ilp32d-non-multilib success Build passed
rivoscibot/toolchain-ci-rivos-test success Testing passed
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 fail Patch failed to apply

Commit Message

Li, Pan2 April 19, 2024, 2:29 p.m. UTC
  From: Pan Li <pan2.li@intel.com>

The RVV register overlap requires both the dest, and src operands.
Thus the rigister filter in constraint cannot cover the fully sematics
of the vector register overlap.

Thus, revert these overlap patches list and xfail the related test
cases.  This patch would like to revert *b3b2799b872*, and the full
picture of related series are listed as below.

[P] b3b2799b872 RISC-V: Support one more overlap for wv instructions
[N] 7e854b58084 RISC-V: Support highest overlap for wv instructions
[N] 018ba3ac952 RISC-V: Fix overlap group incorrect overlap on v0
[N] 27fde325d64 RISC-V: Support highest-number regno overlap for widen ternary
[N] a23415d7572 RISC-V: Support highpart register overlap for widen vx/vf instructions
[N] 4418d55bcd1 RISC-V: Support highpart overlap for indexed load with SRC EEW < DEST EEW
[N] 303195e2a6b RISC-V: Support widening register overlap for vf4/vf8
[N] 8614cbb2534 RISC-V: Support highpart overlap for floating-point widen instructions
[N] e65aaf8efe1 RISC-V: Rename vconstraint into group_overlap
[N] 62685890d88 RISC-V: Support highpart overlap for vext.vf
[N] bdad036da32 RISC-V: Support highpart register overlap for vwcvt
[N] 1a0af6e5a99 RISC-V: Allow dest operand and accumulator operand overlap of widen reduction instruction[PR112327]

Indicator:
[D]: Done, aka this patch has reverted already.
[P]: Patched, aka the revert patch is sent but not merged.
[N]: None, aka not started yet.

The below test suites are passed for this patch.
* The riscv rv64gcv fully regression test.
* The riscv rv64gc fully regression test.

gcc/ChangeLog:

	* config/riscv/riscv.md (none,W21,W42,W84,W43,W86,W87,W0): Remove W0.
	(none,W21,W42,W84,W43,W86,W87): Ditto.
	* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr112431-42.c: Xfail vmv1r asm check.

Signed-off-by: Pan Li <pan2.li@intel.com>
---
 gcc/config/riscv/riscv.md                     | 14 +---
 gcc/config/riscv/vector.md                    | 84 +++++++++----------
 .../gcc.target/riscv/rvv/base/pr112431-42.c   |  2 +-
 3 files changed, 47 insertions(+), 53 deletions(-)
  

Comments

Robin Dapp April 19, 2024, 2:54 p.m. UTC | #1
Hi Pan,

> The RVV register overlap requires both the dest, and src operands.
> Thus the rigister filter in constraint cannot cover the fully sematics
> of the vector register overlap.

I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.

If something is broken then indeed we should revert it.

But...

> Thus, revert these overlap patches list and xfail the related test
> cases.  This patch would like to revert *b3b2799b872*, and the full
> picture of related series are listed as below.

... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear. 

Regards
 Robin
  
Li, Pan2 April 19, 2024, 11:24 p.m. UTC | #2
> I'm not sure I'm following.  Did we miss something that should have been
> covered?  Like only an overlap on the srcs but not the dest?
> Are there testcases that fail?  If so we should definitely have one.

> If something is broken then indeed we should revert it.

Yes, we may need to support these in gcc-15.

> ... why not just revert everything and xfail all the tests in a
> follow up?  Your patch is essentially a revert but doesn't look like
> it.  I'd rather we let a revert be a revert and adjust the tests
> separately so it becomes clear.

Sure, will revert b3b2799b872 and then file the patch for the xfail tests.

Pan

-----Original Message-----
From: Robin Dapp <rdapp.gcc@gmail.com> 
Sent: Friday, April 19, 2024 10:54 PM
To: Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org
Cc: rdapp.gcc@gmail.com; juzhe.zhong@rivai.ai; kito.cheng@gmail.com
Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

Hi Pan,

> The RVV register overlap requires both the dest, and src operands.
> Thus the rigister filter in constraint cannot cover the fully sematics
> of the vector register overlap.

I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.

If something is broken then indeed we should revert it.

But...

> Thus, revert these overlap patches list and xfail the related test
> cases.  This patch would like to revert *b3b2799b872*, and the full
> picture of related series are listed as below.

... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear. 

Regards
 Robin
  
Patrick O'Neill April 22, 2024, 5:20 p.m. UTC | #3
Hi Pan,

>> I'm not sure I'm following.  Did we miss something that should have been
>> covered?  Like only an overlap on the srcs but not the dest?
>> Are there testcases that fail?  If so we should definitely have one.
Can you give some additional information on why these reverts are needed?
+1 to the request for a failing testcase if there is one.Patrick
>> If something is broken then indeed we should revert it.
> Yes, we may need to support these in gcc-15.
>
>> ... why not just revert everything and xfail all the tests in a
>> follow up?  Your patch is essentially a revert but doesn't look like
>> it.  I'd rather we let a revert be a revert and adjust the tests
>> separately so it becomes clear.
> Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
>
> Pan
  
juzhe.zhong@rivai.ai April 22, 2024, 10:07 p.m. UTC | #4
Apologize that we didn't post our (me, kito and Li Pan) disscussions.

This is the story:
We found that my previous patches which support highpart register overlap with register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)

We have tried several fixes to work around this ICE, however, we failed.
And also I found my previous patches are quite wrong which is not the perfect solution to support register group overlap
for vwadd.wv. 
So, finally we decide to revert those patches.

Kito knows the details of this story, kito can share more details in GNU patche meeting.

Thanks.


juzhe.zhong@rivai.ai
 
From: Patrick O'Neill
Date: 2024-04-23 01:20
To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
CC: juzhe.zhong@rivai.ai; kito.cheng@gmail.com
Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests
Hi Pan,
I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.
Can you give some additional information on why these reverts are needed?
+1 to the request for a failing testcase if there is one. Patrick If something is broken then indeed we should revert it.
Yes, we may need to support these in gcc-15.
... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear.
Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
Pan
  
Palmer Dabbelt April 23, 2024, 12:42 a.m. UTC | #5
On Mon, 22 Apr 2024 15:07:59 PDT (-0700), juzhe.zhong@rivai.ai wrote:
> Apologize that we didn't post our (me, kito and Li Pan) disscussions.

Some amount of off-list discussion is inevitable, but as far as I can 
tell here we ended up with some code committed that wasn't even posted 
to the lists and didn't even build.  I don't know exactly where the bar 
for public discussions is, but it's got to be somewhere higher than 
that.

> This is the story:
> We found that my previous patches which support highpart register overlap with register filter for instructions like (vwadd.wv)
> cause ICE reported by:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
> and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)
> 
> We have tried several fixes to work around this ICE, however, we failed.
> And also I found my previous patches are quite wrong which is not the perfect solution to support register group overlap
> for vwadd.wv. 
> So, finally we decide to revert those patches.

Sure, reverting something that has a bug is reasonable.  The problem is 
how this happened: this code clearly did not get tested, as it doesn't 
even build and re-introduces a bunch of ICEs.  We're very late in stage 
4 and this is the second time the entire port has been broken in as many 
weeks.  That's a really bad time to be breaking things.

I think we're really set the wrong precedent on what the bar is for 
review here.  We had a lot of breakages early on in the 14 development 
cycle and never really dug into that, I was hoping that getting CI set 
up would be a strong enough hint to stop the breakages.  Clearly that 
didn't work, though, so:

Please stop breaking the port.

It's exceedingly rare that any patch needs to be committed minutes after 
it's posted.  These port-wide breakages are really the only thing where 
it could be agreed that's the way to go, but as we can see here rushing 
is as likely to dig a bigger hole as it is to fix things.  I get the 
testsuite can be kind of hard to run, but if you don't want to run it 
locally you can just wait for the CI to do it for you.  That's not 
really asking for very much.

> Kito knows the details of this story, kito can share more details in GNU patche meeting.

Ya, we can talk tomorrow morning.

Do you guys have a fix for the regressions that showed up over the 
weekend?

Either way I'd prefer to go with reverting all this and then taking 
Robin's more self-contained fix.  If you guys want to do a bigger change 
later that's fine, we're just really close to the release and it's not a 
good time to risk breaking things.  We've only had a few days of a 
functioning port over the last week or two, that's already put us behind 
on the distro prerelases/RCs so I'm kind of worried something else has 
slipped in.

> 
> Thanks.
> 
> 
> juzhe.zhong@rivai.ai
>  
> From: Patrick O'Neill
> Date: 2024-04-23 01:20
> To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
> CC: juzhe.zhong@rivai.ai; kito.cheng@gmail.com
> Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests
> Hi Pan,
> I'm not sure I'm following.  Did we miss something that should have been
> covered?  Like only an overlap on the srcs but not the dest?
> Are there testcases that fail?  If so we should definitely have one.
> Can you give some additional information on why these reverts are needed?
> +1 to the request for a failing testcase if there is one. Patrick If something is broken then indeed we should revert it.
> Yes, we may need to support these in gcc-15.
> ... why not just revert everything and xfail all the tests in a
> follow up?  Your patch is essentially a revert but doesn't look like
> it.  I'd rather we let a revert be a revert and adjust the tests
> separately so it becomes clear.
> Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
> Pan
>
  
Li, Pan2 April 23, 2024, 1:44 a.m. UTC | #6
> Sure, reverting something that has a bug is reasonable.  The problem is 
> how this happened: this code clearly did not get tested, as it doesn't 
> even build and re-introduces a bunch of ICEs.  We're very late in stage 
> 4 and this is the second time the entire port has been broken in as many 
> weeks.  That's a really bad time to be breaking things.

Thanks Palmer to point this out. Let me share more details about the process.
The revert is not just a git command like git revert commit-id. Consider below scenario.

Day-1: commit-A: rename a attribute.
Day-2: commit-B: other patches reference this renamed attribute but no need to revert.

To follow the suggestion of Robin that keeping the revert commit pure, I followed below step(s)

1. Revert commit-A locally, and address the reference issue.
2. Run fully test to see if any surprise (take 80-90 mins for 64 cores. Sorry again only c/c++ parts, Fortran is missing here).
3. Revert commit-A to upstream (of course it will result in built failure).
4. File patch to address the reference attribute issue.

The other revert almost take similar step(s) but looks some mistake here.
Sorry for that each test result is comparing between code change and upstream, and it will be missed after
we moving on.

> Do you guys have a fix for the regressions that showed up over the 
> weekend?

Understand current we are in the sensitive stage, will take care of the failures ASAP.

Pan

-----Original Message-----
From: Palmer Dabbelt <palmer@dabbelt.com> 
Sent: Tuesday, April 23, 2024 8:43 AM
To: juzhe.zhong@rivai.ai
Cc: Patrick O'Neill <patrick@rivosinc.com>; Li, Pan2 <pan2.li@intel.com>; Robin Dapp <rdapp.gcc@gmail.com>; gcc-patches@gcc.gnu.org; Kito Cheng <kito.cheng@gmail.com>
Subject: Re: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

On Mon, 22 Apr 2024 15:07:59 PDT (-0700), juzhe.zhong@rivai.ai wrote:
> Apologize that we didn't post our (me, kito and Li Pan) disscussions.

Some amount of off-list discussion is inevitable, but as far as I can 
tell here we ended up with some code committed that wasn't even posted 
to the lists and didn't even build.  I don't know exactly where the bar 
for public discussions is, but it's got to be somewhere higher than 
that.

> This is the story:
> We found that my previous patches which support highpart register overlap with register filter for instructions like (vwadd.wv)
> cause ICE reported by:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
> and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)
> 
> We have tried several fixes to work around this ICE, however, we failed.
> And also I found my previous patches are quite wrong which is not the perfect solution to support register group overlap
> for vwadd.wv. 
> So, finally we decide to revert those patches.

Sure, reverting something that has a bug is reasonable.  The problem is 
how this happened: this code clearly did not get tested, as it doesn't 
even build and re-introduces a bunch of ICEs.  We're very late in stage 
4 and this is the second time the entire port has been broken in as many 
weeks.  That's a really bad time to be breaking things.

I think we're really set the wrong precedent on what the bar is for 
review here.  We had a lot of breakages early on in the 14 development 
cycle and never really dug into that, I was hoping that getting CI set 
up would be a strong enough hint to stop the breakages.  Clearly that 
didn't work, though, so:

Please stop breaking the port.

It's exceedingly rare that any patch needs to be committed minutes after 
it's posted.  These port-wide breakages are really the only thing where 
it could be agreed that's the way to go, but as we can see here rushing 
is as likely to dig a bigger hole as it is to fix things.  I get the 
testsuite can be kind of hard to run, but if you don't want to run it 
locally you can just wait for the CI to do it for you.  That's not 
really asking for very much.

> Kito knows the details of this story, kito can share more details in GNU patche meeting.

Ya, we can talk tomorrow morning.

Do you guys have a fix for the regressions that showed up over the 
weekend?

Either way I'd prefer to go with reverting all this and then taking 
Robin's more self-contained fix.  If you guys want to do a bigger change 
later that's fine, we're just really close to the release and it's not a 
good time to risk breaking things.  We've only had a few days of a 
functioning port over the last week or two, that's already put us behind 
on the distro prerelases/RCs so I'm kind of worried something else has 
slipped in.

> 
> Thanks.
> 
> 
> juzhe.zhong@rivai.ai
>  
> From: Patrick O'Neill
> Date: 2024-04-23 01:20
> To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
> CC: juzhe.zhong@rivai.ai; kito.cheng@gmail.com
> Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests
> Hi Pan,
> I'm not sure I'm following.  Did we miss something that should have been
> covered?  Like only an overlap on the srcs but not the dest?
> Are there testcases that fail?  If so we should definitely have one.
> Can you give some additional information on why these reverts are needed?
> +1 to the request for a failing testcase if there is one. Patrick If something is broken then indeed we should revert it.
> Yes, we may need to support these in gcc-15.
> ... why not just revert everything and xfail all the tests in a
> follow up?  Your patch is essentially a revert but doesn't look like
> it.  I'd rather we let a revert be a revert and adjust the tests
> separately so it becomes clear.
> Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
> Pan
>
  
Jeff Law April 25, 2024, 2:16 p.m. UTC | #7
On 4/22/24 4:07 PM, 钟居哲 wrote:
> Apologize that we didn't post our (me, kito and Li Pan) disscussions.
> 
> This is the story:
> We found that my previous patches which support highpart register 
> overlap with register filter for instructions like (vwadd.wv)
> cause ICE reported by:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 <https:// 
> gcc.gnu.org/bugzilla/show_bug.cgi?id=114714>
> and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)
Just a note for the future, this wouldn't really be considered a 
regression since GCC-13 didn't have any vector support.  I'm happy to 
help with this kind of judgment call, as are many other GCC developers 
such as Jakub, Richi, etc.  We've been making these kinds of judgment 
calls for decades.

> 
> We have tried several fixes to work around this ICE, however, we failed.
> And also I found my previous patches are quite wrong which is not the 
> perfect solution to support register group overlap
> for vwadd.wv.
> So, finally we decide to revert those patches.
It would have been useful to bring others into the discussion.  Both 
Robin and I would have likely wanted to understand why disabling the 
alternative wasn't sufficient.

Looking at this more generally, we need to keep in mind that the closer 
we get to a release, the more careful we need to be.  We can take the 
time to bring more engineers into the technical discussion.  We can take 
the time to evaluate the pros/cons of different approaches and balance 
them against the needs of the upcoming release and other factors that 
may come into play.

So let's learn, adjust & move on.

Thanks,
jeff
  

Patch

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c2b4323c53a..f0928398698 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -541,7 +541,7 @@  (define_attr "fp_vector_disabled" "no,yes"
 ;; Widening instructions have group-overlap constraints.  Those are only
 ;; valid for certain register-group sizes.  This attribute marks the
 ;; alternatives not matching the required register-group size as disabled.
-(define_attr "group_overlap" "none,W21,W42,W84,W43,W86,W87,W0"
+(define_attr "group_overlap" "none,W21,W42,W84,W43,W86,W87"
   (const_string "none"))
 
 (define_attr "group_overlap_valid" "no,yes"
@@ -562,9 +562,9 @@  (define_attr "group_overlap_valid" "no,yes"
 
          ;; According to RVV ISA:
          ;; The destination EEW is greater than the source EEW, the source EMUL is at least 1,
-         ;; and the overlap is in the highest-numbered part of the destination register group
-         ;; (e.g., when LMUL=8, vzext.vf4 v0, v6 is legal, but a source of v0, v2, or v4 is not).
-         ;; So the source operand should have LMUL >= 1.
+	 ;; and the overlap is in the highest-numbered part of the destination register group
+	 ;; (e.g., when LMUL=8, vzext.vf4 v0, v6 is legal, but a source of v0, v2, or v4 is not).
+	 ;; So the source operand should have LMUL >= 1.
          (and (eq_attr "group_overlap" "W43")
 	      (match_test "riscv_get_v_regno_alignment (GET_MODE (operands[0])) != 4
 			   && riscv_get_v_regno_alignment (GET_MODE (operands[3])) >= 1"))
@@ -574,12 +574,6 @@  (define_attr "group_overlap_valid" "no,yes"
 	      (match_test "riscv_get_v_regno_alignment (GET_MODE (operands[0])) != 8
 			   && riscv_get_v_regno_alignment (GET_MODE (operands[3])) >= 1"))
 	 (const_string "no")
-
-         ;; W21 supports highest-number overlap for source LMUL = 1.
-         ;; For 'wv' variant, we can also allow wide source operand overlaps dest operand.
-         (and (eq_attr "group_overlap" "W0")
-	      (match_test "riscv_get_v_regno_alignment (GET_MODE (operands[0])) > 1"))
-	 (const_string "no")
         ]
        (const_string "yes")))
 
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 8b1c24c5d79..8298a72b771 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -3842,48 +3842,48 @@  (define_insn "@pred_dual_widen_<any_widen_binop:optab><any_extend:su><mode>_scal
    (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_sub<any_extend:su><mode>"
-  [(set (match_operand:VWEXTI 0 "register_operand"                 "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr,  &vr,  &vr, ?&vr, ?&vr")
+  [(set (match_operand:VWEXTI 0 "register_operand"             "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, ?&vr, ?&vr")
 	(if_then_else:VWEXTI
 	  (unspec:<VM>
-	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1,vmWc1,vmWc1")
-	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK,   rK,   rK")
-	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
+	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1")
+	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK")
+	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
 	     (reg:SI VL_REGNUM)
 	     (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
 	  (minus:VWEXTI
-	    (match_operand:VWEXTI 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,    0,    0,   vr,   vr")
+	    (match_operand:VWEXTI 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,   vr,   vr")
 	    (any_extend:VWEXTI
-	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr,   vr,   vr")))
-	  (match_operand:VWEXTI 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0,   vu,    0")))]
+	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr")))
+	  (match_operand:VWEXTI 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0")))]
   "TARGET_VECTOR"
   "vwsub<any_extend:u>.wv\t%0,%3,%4%p1"
   [(set_attr "type" "viwalu")
    (set_attr "mode" "<V_DOUBLE_TRUNC>")
-   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,W0,W0,none,none")])
+   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_add<any_extend:su><mode>"
-  [(set (match_operand:VWEXTI 0 "register_operand"                 "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr,  &vr,  &vr, ?&vr, ?&vr")
+  [(set (match_operand:VWEXTI 0 "register_operand"             "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, ?&vr, ?&vr")
 	(if_then_else:VWEXTI
 	  (unspec:<VM>
-	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1,vmWc1,vmWc1")
-	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK,   rK,   rK")
-	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
+	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1")
+	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK")
+	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
 	     (reg:SI VL_REGNUM)
 	     (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
 	  (plus:VWEXTI
 	    (any_extend:VWEXTI
-	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr,   vr,   vr"))
-	    (match_operand:VWEXTI 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,    0,    0,   vr,   vr"))
-	  (match_operand:VWEXTI 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0,   vu,    0")))]
+	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr"))
+	    (match_operand:VWEXTI 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,   vr,   vr"))
+	  (match_operand:VWEXTI 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0")))]
   "TARGET_VECTOR"
   "vwadd<any_extend:u>.wv\t%0,%3,%4%p1"
   [(set_attr "type" "viwalu")
    (set_attr "mode" "<V_DOUBLE_TRUNC>")
-   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,W0,W0,none,none")])
+   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_<plus_minus:optab><any_extend:su><mode>_scalar"
   [(set (match_operand:VWEXTI 0 "register_operand"                   "=vr,   vr")
@@ -7143,56 +7143,56 @@  (define_insn "@pred_dual_widen_<optab><mode>_scalar"
    (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_add<mode>"
-  [(set (match_operand:VWEXTF 0 "register_operand"                 "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr,  &vr,  &vr, ?&vr, ?&vr")
+  [(set (match_operand:VWEXTF 0 "register_operand"             "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, ?&vr, ?&vr")
 	(if_then_else:VWEXTF
 	  (unspec:<VM>
-	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1,vmWc1,vmWc1")
-	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK,   rK,   rK")
-	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 9 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
+	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1")
+	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK")
+	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 9 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
 	     (reg:SI VL_REGNUM)
 	     (reg:SI VTYPE_REGNUM)
 	     (reg:SI FRM_REGNUM)] UNSPEC_VPREDICATE)
 	  (plus:VWEXTF
 	    (float_extend:VWEXTF
-	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr,   vr,   vr"))
-	    (match_operand:VWEXTF 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,    0,    0,   vr,   vr"))
-	  (match_operand:VWEXTF 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0,   vu,    0")))]
+	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr"))
+	    (match_operand:VWEXTF 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,   vr,   vr"))
+	  (match_operand:VWEXTF 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0")))]
   "TARGET_VECTOR"
   "vfwadd.wv\t%0,%3,%4%p1"
   [(set_attr "type" "vfwalu")
    (set_attr "mode" "<V_DOUBLE_TRUNC>")
    (set (attr "frm_mode")
 	(symbol_ref "riscv_vector::get_frm_mode (operands[9])"))
-   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,W0,W0,none,none")])
+   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_sub<mode>"
-  [(set (match_operand:VWEXTF 0 "register_operand"                 "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr,  &vr,  &vr, ?&vr, ?&vr")
+  [(set (match_operand:VWEXTF 0 "register_operand"             "=vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, vd, vr, ?&vr, ?&vr")
 	(if_then_else:VWEXTF
 	  (unspec:<VM>
-	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1,vmWc1,vmWc1")
-	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK,   rK,   rK")
-	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
-	     (match_operand 9 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i,    i,    i")
+	    [(match_operand:<VM> 1 "vector_mask_operand"           " vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1, vm,Wc1,vmWc1,vmWc1")
+	     (match_operand 5 "vector_length_operand"              " rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK, rK,   rK,   rK")
+	     (match_operand 6 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 7 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 8 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
+	     (match_operand 9 "const_int_operand"                  "  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,  i,    i,    i")
 	     (reg:SI VL_REGNUM)
 	     (reg:SI VTYPE_REGNUM)
 	     (reg:SI FRM_REGNUM)] UNSPEC_VPREDICATE)
 	  (minus:VWEXTF
-	    (match_operand:VWEXTF 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,    0,    0,   vr,   vr")
+	    (match_operand:VWEXTF 3 "register_operand"             " vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr, vr,   vr,   vr")
 	    (float_extend:VWEXTF
-	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr,   vr,   vr")))
-	  (match_operand:VWEXTF 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0,   vu,    0")))]
+	      (match_operand:<V_DOUBLE_TRUNC> 4 "register_operand" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,   vr,   vr")))
+	  (match_operand:VWEXTF 2 "vector_merge_operand"           " vu, vu,  0,  0, vu, vu,  0,  0, vu, vu,  0,  0,   vu,    0")))]
   "TARGET_VECTOR"
   "vfwsub.wv\t%0,%3,%4%p1"
   [(set_attr "type" "vfwalu")
    (set_attr "mode" "<V_DOUBLE_TRUNC>")
    (set (attr "frm_mode")
 	(symbol_ref "riscv_vector::get_frm_mode (operands[9])"))
-   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,W0,W0,none,none")])
+   (set_attr "group_overlap" "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
 
 (define_insn "@pred_single_widen_<plus_minus:optab><mode>_scalar"
   [(set (match_operand:VWEXTF 0 "register_operand"                   "=vr,   vr")
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-42.c b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-42.c
index 1ee5b20a899..fa5dac58a20 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-42.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-42.c
@@ -21,7 +21,7 @@  reduc_plus_float (float *__restrict a, int n)
   return r;
 }
 
-/* { dg-final { scan-assembler-not {vmv1r} } } */
+/* { dg-final { scan-assembler-not {vmv1r} { xfail riscv*-*-* } } } */
 /* { dg-final { scan-assembler-not {vmv2r} } } */
 /* { dg-final { scan-assembler-not {vmv4r} } } */
 /* { dg-final { scan-assembler-not {vmv8r} } } */