RISC-V: Fix regressions due to 86de9b66480b710202a2898cf513db105d8c432f
Checks
Commit Message
This patch fixes the recent regression:
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -O3 -g (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c -Os (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c -Os (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -O1 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -O2 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -O3 -g (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c -Os (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c -Os (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O1 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O2 (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -O3 -g (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c -Os (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c -Os (test for excess errors)
due to commit 86de9b66480b710202a2898cf513db105d8c432f.
The root cause is register_operand and reg_or_subregno are consistent so we reach the assertion fail.
We shouldn't worry about subreg:...VL_REGNUM since it's impossible that we can have such situation,
that is, we only have (set (reg) (reg:VL_REGNUM)) which generate "csrr vl" ASM for first fault load instructions (vleff).
So, using REG_P and REGNO must be totally solid and robostic.
Since we don't allow VL_RENUM involved into register allocation and we don't have such constraint, we always use this
following pattern to generate "csrr vl" ASM:
(define_insn "read_vlsi"
[(set (match_operand:SI 0 "register_operand" "=r")
(reg:SI VL_REGNUM))]
"TARGET_VECTOR"
"csrr\t%0,vl"
[(set_attr "type" "rdvl")
(set_attr "mode" "SI")])
So the check in riscv.md is to disallow such situation fall into move pattern in riscv.md
Tested on both RV32/RV64 no regression.
PR target/109092
gcc/ChangeLog:
* config/riscv/riscv.md: Use reg instead of subreg.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr109092.c: New test.
---
gcc/config/riscv/riscv.md | 6 ++----
gcc/testsuite/gcc.target/riscv/rvv/base/pr109092.c | 4 ++++
2 files changed, 6 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr109092.c
Comments
Hi Juzhe,
in principle this seems ok to me but I wonder about:
> We shouldn't worry about subreg:...VL_REGNUM since it's impossible
> that we can have such situation,
I think we allow this in legitimize_move for situations like
(subreg:SI (reg:V4QI)). That was not added for correctness but
optimization - are we sure we don't undo this optimization with
that change?
Regards
Robin
No, we didn't undo the optimization.
We just disallow move pattern for (set (reg) (VL_REGNUM)).
juzhe.zhong@rivai.ai
From: Robin Dapp
Date: 2024-01-22 19:25
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Fix regressions due to 86de9b66480b710202a2898cf513db105d8c432f
Hi Juzhe,
in principle this seems ok to me but I wonder about:
> We shouldn't worry about subreg:...VL_REGNUM since it's impossible
> that we can have such situation,
I think we allow this in legitimize_move for situations like
(subreg:SI (reg:V4QI)). That was not added for correctness but
optimization - are we sure we don't undo this optimization with
that change?
Regards
Robin
> No, we didn't undo the optimization.
>
> We just disallow move pattern for (set (reg) (VL_REGNUM)).
Ah, what I referred to was the opposite direction. We allow
(subreg:V8QI (reg:DI ...)) which is not touched by this patch.
Then it is OK.
Regards
Robin
@@ -1776,8 +1776,7 @@
(zero_extend:DI
(match_operand:SI 1 "nonimmediate_operand" " r,m")))]
"TARGET_64BIT && !TARGET_ZBA && !TARGET_XTHEADBB && !TARGET_XTHEADMEMIDX
- && !(register_operand (operands[1], SImode)
- && reg_or_subregno (operands[1]) == VL_REGNUM)"
+ && !(REG_P (operands[1]) && VL_REG_P (REGNO (operands[1])))"
"@
#
lwu\t%0,%1"
@@ -2214,8 +2213,7 @@
(match_operand:SI 1 "move_operand" " r,T,m,rJ,*r*J,*m,*f,*f,vp"))]
"(register_operand (operands[0], SImode)
|| reg_or_0_operand (operands[1], SImode))
- && !(register_operand (operands[1], SImode)
- && reg_or_subregno (operands[1]) == VL_REGNUM)"
+ && !(REG_P (operands[1]) && VL_REG_P (REGNO (operands[1])))"
{ return riscv_output_move (operands[0], operands[1]); }
[(set_attr "move_type" "move,const,load,store,mtc,fpload,mfc,fpstore,rdvlenb")
(set_attr "mode" "SI")
new file mode 100644
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-mabi=lp64d -march=rv64imafdc" } */
+
+void foo(int i) {}