On 6/2/2026 8:30 AM, Jin Ma wrote:
Hi,
While investigating vsetvl ping-ponging cases recently, the ready
queue reordering hook riscv_sched_reorder was found to contain an
unconditional return that makes most of the body unreachable:
if (!last_vconfig.valid || *nreadyp == 1)
return riscv_issue_rate ();
return riscv_issue_rate (); /* dead, kills reordering below. */
int nready = *nreadyp;
...
The hook was introduced by commit 63632889651 ("[RISC-V] Reorder
ready queue slightly to avoid unnecessary vsetvl instructions"). It
is unclear whether the second return was intentional (e.g. left as a
temporary guard) or a leftover. Either way, since the surrounding
code is specifically designed to group instructions with the same
vector configuration and reduce vsetvl ping-ponging, the dead return
defeats the hook's stated purpose.
Remove the dead return so the reordering can actually run.
A quick look at the resulting fallout is benign: re-enabling the
reordering changes the vsetvl emission pattern for the zve64f
testcases pr111037-1.c, pr111037-4.c and pr113248.c. The reorder
now places vle64.v + vadd.vv (both with mode-derived SEW=64) before
vfmv.s.f (SEW=16), so the vsetvl pass emits
vsetivli zero, 1, e64, m1
...
vsetivli zero, 1, e16, m1
instead of the prior
vsetivli zero, 1, e16, mf4
...
vsetvli zero, zero, e64, m1
Both sequences contain two vsetvl insns, so the total switching cost
is unchanged. Updating the scan-assembler-times patterns to match
the new sequence therefore looks like a reasonable adjustment.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_reorder): Remove dead
return after the early-return guard.
gcc/testsuite/ChangeLog:
PR target/111037
PR target/113248
* gcc.target/riscv/rvv/vsetvl/pr111037-1.c: Update vsetvl
patterns to match post-reorder asm sequence.
* gcc.target/riscv/rvv/vsetvl/pr111037-4.c: Likewise.
* gcc.target/riscv/rvv/vsetvl/pr113248.c: Likewise.
Most likely a merge error on my part. Thanks for finding and fixing.
And I'd expect any benefit to be minor at best.
OK for the trunk.
jeff
