On 10/9/26 3:29 AM, Jin Ma wrote:
For example, C9501's integer load-pair fusion operations do not support
lb or lh, so the eligibility check excludes them. The ARC-V design
Michiel described supports fusing loads of 2 or 4 bytes, but not 8
bytes. Rules expressing those restrictions could admit accesses of 2
bytes such as lh and exclude ld. This would keep each design's
restrictions in its own rules.
And as a point of reference I expect we'll see a highly general pair
fusion for integer loads/stores which can fuse pairs of 1, 2, 4, or 8
byte memory references. Once you build out the basic machinery,
handling more cases is straightforward.
My understanding is that TARGET_SCHED_FUSION_PRIORITY is intended to
guide grouping and ordering during scheduling. For eligible
instructions, the hook computes fusion_pri from the register file,
load/store kind, mode and base, and then computes pri within the group
from the offset and the supported direction. Even if many loads pass the
eligibility checks, this grouping and ordering may still help. For
example, on a design that supports fusing loads of 8 bytes in decreasing
address order, these independent instructions:
ld a1,0(a0)
add a3,a4,a5
ld a2,8(a0)
These priorities can encourage the scheduler to arrange them as follows:
ld a2,8(a0)
ld a1,0(a0)
add a3,a4,a5
Right. That's precisely what I would expect.
Movement remains constrained by the scheduler's dependency analysis. The
full matcher checks the common base, adjacent offsets, alignment and
register relationships required for an actual pair. This grouping and
ordering is a scheduling heuristic; it does not establish that every
candidate has a fusible partner. A candidate can pass the eligibility
check but still fail to fuse because the offsets are not adjacent or
other pair constraints are not satisfied. Searching explicitly for
fusion partners is still worth investigating.
Right. THe scheduler is the natural place for this because of its
dependency analysis.
My intention is to use the existing hook for the grouping and ordering
above, as a relatively small scheduling improvement. If you consider
this approach unsuitable, see shortcomings in its design, or think it
would be better to handle this directly through pair-fusion, we can set
this patch aside despite its small scope and pursue that direction in
later work :)
I think as long as we're taking inspiration from the aarch64 port, then
we're largely on the right track. I've done a few implementations of
this through the years in GCC; aarch64 has the strongest implementation
I've seen.
I can later investigate a RISC-V implementation of the pair-fusion pass
and evaluate its benefits. If it shows a clear benefit, I will try to
prepare a patch for review.
Sounds good!
In prior experiences we could see the results directly and indirectly.
For example, I worked on one design where we could look at the
differences in average number of bytes handled by loads/stores through
the execution of a benchmark -- clearly in that design we were
targetting a load/store pair instruction. In other cases I've worked on
we could see it in the low level signaling data from the decoder or
retirement units. I expect no different from the design we're working
on right now based on the data I've seen to date.
jeff
