On 9/4/26 3:53 PM, Andrea Pinski wrote:
On Sun, Aug 16, 2026 at 11:21 PM Jin Ma <[email protected]> wrote:
The sched_fusion pass can bring independent memory accesses together
before sched2. Add a priority hook that groups scalar load/store-pair
candidates by register file, access kind, mode and base register, then
orders each group by offset. Prefer decreasing offsets when both
directions are available, matching frame save/restore memory order.
Enable scheduling fusion by default for load/store-pair tunes while
preserving an explicit -f[no-]schedule-fusion option. Keep the positive
test as XFAIL until the tuning patch enables the pairs.
Static sched2 macro-fusion counts for SPEC CPU 2017 Integer built with
-O3 -flto, measured independently of ready-list reordering against a
baseline with xt-c9501fdvt fusion pairs enabled:
Benchmark Baseline With patch Change
500.perlbench_r 15302 17077 +11.6%
502.gcc_r 72806 78135 +7.3%
505.mcf_r 63 85 +34.9%
520.omnetpp_r 20479 22084 +7.8%
523.xalancbmk_r 42442 44651 +5.2%
525.x264_r 6232 7033 +12.9%
531.deepsjeng_r 299 328 +9.7%
541.leela_r 794 851 +7.2%
548.exchange2_r 353 426 +20.7%
557.xz_r 1217 1321 +8.5%
SUM 159987 171991 +7.5%
se
I have not looked into this fully but there is a secondary pass which
needs to be extended for riscv load/store fusion called pair-fusion.cc
It is different from the scheduling passes (sched_fusion and
pass_dep_fusion) in that it has its own mechanisms to do the fusion
and it uses aliasing info. It is currently used for aarch64 for
load/store pair formation (and there were patches to do a similar
thing for power). The pass was split out into a target independent
part and a target specific part when the pass was extended for power.
Maybe this could be used for this case?
It's on my list of things to investigate. I expect we'll see designs
with load/store pair fusion that can be modeled in a manner similar to
aarch64, except that we don't form a new insn, but just bring the fused
pair together. Since there's no data dependency this case is slightly
harder (but arguably more important) than many of the more traditional
pairwise fusions.
We've already seen designs with varying implementations of store pair
fusion that would be helped by more aggressively bringing stores together.
jeff
