]> git.ipfire.org Git - thirdparty/gcc.git/commitdiff
[RISC-V][V2] Improve spill code for RVV slightly to fix regressions after recent...
authorJeff Law <jlaw@ventanamicro.com>
Mon, 22 Dec 2025 17:54:05 +0000 (10:54 -0700)
committerJeff Law <jlaw@ventanamicro.com>
Mon, 22 Dec 2025 17:55:45 +0000 (10:55 -0700)
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.

gcc/testsuite/gcc.target/riscv/rvv/base/spill-7.c

index 2bc54557deecf3aaa1721b98d02d484ad29400af..865a95a0fb97041bfb5fb9512f1945de801978b1 100644 (file)
 **  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]+\)