On 6/2/2026 12:51, Jeffrey Law wrote:
>
>
>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.
Hi Jeff,
Thanks for the quick response and for clarifying the background.
I've been investigating some vsetvl ping-ponging cases recently,
and found two distinct scenarios:
1. Intrinsic-based libraries:
In hand-written intrinsic code (e.g., some OpenCV operators), sched1
interleaves instructions with different vtype configurations even when
no data dependency exists between them. Since vsetvl instructions have
not yet been generated at that stage, sched1 has no way to account for
the vsetvl switching cost, causing what would have been 2 vsetvl insns
in the original assembly to balloon to 5. This results in noticeable
performance regressions -- over 10% slowdown on some OpenCV operators.
Performance recovers when -fno-schedule-insns is used, which confirms
sched1 is the culprit.
2. Auto-vectorization:
On some benchmarks such as 525.x264_r, we also observe excessive vsetvl
switching in hot loops. However, from my analysis, by the time sched1
runs, the instructions already have severe data dependencies, leaving
little room for rescheduling to help.
For case 1, I am exploring an approach of introducing a virtual vsetvl
cost model into the scheduling logic -- essentially teaching the scheduler
to weigh vsetvl switching overhead against data dependency constraints
(WAW, etc.) when making issue decisions. Your TARGET_SCHED_REORDER hook
is a good starting point, but it only reorders within the same priority
level, which may not be sufficient when conflicting instructions happen
to have different priorities. Do you have any suggestions on a better
way to model the vsetvl switching cost earlier in the pipeline, perhaps
by injecting artificial dependencies between instructions with incompatible
vtype configurations via TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK?
For case 2, I have not yet found a good solution. It is possible that
this is simply an inherent characteristic of RVV's programming model.
Any thoughts or pointers would be greatly appreciated.
>OK for the trunk.
Thanks. I've pushed this to the trunk.
Best regards,
Jin
