https://gcc.gnu.org/g:6c97aedcbc255d1e30a051dbbfa14b8e947e71a1
commit r16-6335-g6c97aedcbc255d1e30a051dbbfa14b8e947e71a1 Author: Jeff Law <[email protected]> Date: Mon Dec 22 10:54:05 2025 -0700 [RISC-V][V2] Improve spill code for RVV slightly to fix regressions after recent changes Surya's recent patch for hard register propagation has caused regressions on the RISC-V port for the various spill-* testcases. After reviewing the newer generated code it was clear the new code was worse. The core problem is we have a copy insn that is not frame related (and should not be frame related) and a use of the destination of the copy in an insn that is frame related. Prior to Surya's change we could propagate away the copy, but not anymore. Ideally we'd just avoid generating the copy entirely, but the structure of the code to legitimize a poly_int isn't well suited for that. So instead we have the code signal that it created a trivial copy and we try to optimize the code after creation, but well before regcprop would have run. That fixes the code quality aspect of the regression. In fact, it looks like the code can at times be slightly better, but I didn't track down the precise reason why we were able to re-use the read of VLEN so much better then before. The optimization step is pretty simple. When it's been signaled that a copy was generated, look back one insn and change it from writing the scratch register to write the final destination instead. That triggers the need to generalize the testcases so that they don't use specific registers. We can also see the csr reads of the VLEN register getting CSE'd more often in those testcases, so they're adjusted for that change as well. There's some hope this will improve spill code more generally -- I haven't really evaluated that, but I do know that when we spill vector registers, the resulting code seems to have a lot of redundant VLEN reads. Anyway, bootstrapped and regression tested on riscv (BPI and Pioneer). It's also been through rv32 and rv64 regression testing. It doesn't fix all the regressions for RISC-V on the trunk because (of course) something new got introduced this week ;( [ This is the spill-7 part of my last commit. After reviewing the logs from the pre-commit system, it's good. ] gcc/testsuite * gcc.target/riscv/rvv/base/spill-7.c: Update expected output. Diff: --- gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c index 2bc54557deec..865a95a0fb97 100644 --- a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c @@ -19,31 +19,26 @@ ** addi\t[a-x0-9]+,[a-x0-9]+,1 ** vsetvli\t[a-x0-9]+,zero,e8,mf4,ta,ma ** vle8.v\tv[0-9]+,0\([a-x0-9]+\) -** csrr\t[a-x0-9]+,vlenb ** srli\t[a-x0-9]+,[a-x0-9]+,2 ** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** vse8.v\tv[0-9]+,0\([a-x0-9]+\) ** addi\t[a-x0-9]+,[a-x0-9]+,2 ** vsetvli\t[a-x0-9]+,zero,e8,mf2,ta,ma ** vle8.v\tv[0-9]+,0\([a-x0-9]+\) -** csrr\t[a-x0-9]+,vlenb ** srli\t[a-x0-9]+,[a-x0-9]+,1 ** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** vse8.v\tv[0-9]+,0\([a-x0-9]+\) ** addi\t[a-x0-9]+,[a-x0-9]+,3 ** vl1re8.v\tv[0-9]+,0\([a-x0-9]+\) -** csrr\t[a-x0-9]+,vlenb ** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** vs1r.v\tv[0-9]+,0\([a-x0-9]+\) ** addi\t[a-x0-9]+,[a-x0-9]+,4 ** vl2re8.v\tv[0-9]+,0\([a-x0-9]+\) -** csrr\t[a-x0-9]+,vlenb ** slli\t[a-x0-9]+,[a-x0-9]+,1 ** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** vs2r.v\tv[0-9]+,0\([a-x0-9]+\) ** addi\t[a-x0-9]+,[a-x0-9]+,5 ** vl4re8.v\tv[0-9]+,0\([a-x0-9]+\) -** mv\t[a-x0-9]+,[a-x0-9]+ ** slli\t[a-x0-9]+,[a-x0-9]+,2 ** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** vs4r.v\tv[0-9]+,0\([a-x0-9]+\) @@ -66,8 +61,6 @@ ** vle8.v\tv[0-9]+,0\([a-x0-9]+\) ** vse8.v\tv[0-9]+,0\([a-x0-9]+\) ** addi\t[a-x0-9]+,[a-x0-9]+,2 -** srli\t[a-x0-9]+,[a-x0-9]+,1 -** add\t[a-x0-9]+,[a-x0-9]+,[a-x0-9]+ ** ... ** vle8.v\tv[0-9]+,0\([a-x0-9]+\) ** vse8.v\tv[0-9]+,0\([a-x0-9]+\)
