> 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% > > > 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? > > Thanks, > Andrea >
Hi Andrea, Thank you for pointing me to this pass. I have looked at pair-fusion.cc and its AArch64 implementation. The common logic for finding candidate memory accesses and moving them using alias analysis is worth considering here. The current framework uses gen_pair to generate a recognizable paired RTL pattern, combining the two accesses into one RTL instruction. The macro-fusion sequences handled by this patch still consist of two scalar instructions. Using that framework would therefore require deciding how to represent the pair and keep the two instructions adjacent through subsequent scheduling and output. For example, we could use a combined pattern that emits two instructions, or extend the common framework to retain separate instructions. This does not rule out reusing its search and alias analysis mechanisms. The current changes still use sched_fusion to bring candidates together, with the full macro-fusion matcher checking actual pairs. Eligibility checking for individual instructions and the full matcher now share memory rules covering access width, register file, direction and offset alignment. These target rules could also provide a basis for a future integration with pair-fusion.cc. For now, I would prefer to keep this patch focused on extending the existing scheduling machinery, while considering your suggestion for further evaluation. Is my understanding of the pair representation and the scope for reuse correct? Thanks, Jin
