]> git.ipfire.org Git - thirdparty/gcc.git/commit
[RISC-V] Reorder ready queue slightly to avoid unnecessary vsetvl instructions
authorJeff Law <jlaw@ventanamicro.com>
Sat, 1 Nov 2025 22:27:05 +0000 (16:27 -0600)
committerJeff Law <jlaw@ventanamicro.com>
Sat, 1 Nov 2025 22:27:05 +0000 (16:27 -0600)
commit63632889651f310ed0dace3d705efa50080c03dd
tree7f8b8be042ff56d899ace5f61fc15ada0840a668
parentac3eeb987ad04923ddc57a9dc9bd4ec98146a981
[RISC-V] Reorder ready queue slightly to avoid unnecessary vsetvl instructions

As I've touched on before, particularly in the patchwork meeting, we can get a
modest reduction in the number of vsetvl instructions we emit by being somewhat
smarter in how we pull instructions out of the ready queue during scheduling.

Each insn in the scheduler's ready queue has a priority which reflects the how
that insn plays in a region's critical path.  The higher the priority, the more
important it is for that instruction to issue.

When we have multiple insns with the same priority in the ready queue, we can
roughly expect that issuing any insn from that set is equally good.  Yes there
are secondary sort keys that incorporate register lifetime and such, but those
are just that -- secondary concerns.

Given some set of insns with the same priority, we can select whichever one we
want, so select the insn with the same vector configuration as whatever vector
instruction was last issued from the ready queue.

This will naturally tend to group vector instructions with the same vector
configuration together, thus reducing the ping-ponging of vector configurations
that we sometimes see.

When I initially cobbled this together (about a year ago) Robin reported low
single digit improvements on the BPI for x264.  A lot has changed since then
and it may not be as big a win now, but I think it still has value.

This did expose that one of the move patterns in vector.md didn't have the
proper vl_op/vtype_op attributes on it.  Trivially fixed.

Tested for riscv32-elf, riscv64-elf and on the Pioneer with no regressions (of
course the Pioneer won't really exercise this code). BPI is in flight, but not
due to complete for ~24hrs.  We've also been running this internally for
roughly a year ðŸ™‚

* config/riscv/riscv-protos.h (has_vtype_op): Add prototype.
(mask_agnostic_p, get_avl, vsetvl_insn_p): Likewise.
* config/riscv/riscv-vsetvl.cc (has_vtype_op): No longer static.
(vsetvl_insn_p, get_avl_mask_agnostic_p): Likewise.
* config/riscv/riscv.cc (struct last_vcofnig): New structure.
(clear_vconfig): New function.
(compatible_with_last_vconfig, riscv_sched_init): Likewise.
(riscv_sched_reorder): Likewise.
(TARGET_SCHED_INIT, TARGET_SCHED_REORDER): Define.
* config/riscv/vector.md ("*mov<mode>"): Set has_vtype_op, has_vl_op
attributes.
gcc/.simplify-rtx.cc.swo [new file with mode: 0644]
gcc/config/riscv/riscv-protos.h
gcc/config/riscv/riscv-vsetvl.cc
gcc/config/riscv/riscv.cc
gcc/config/riscv/vector.md