> 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
Hi Jeff, Thank you for your suggestions. I will continue investigating the pair-fusion pass and try to prepare a patch for review if it shows a clear benefit. I put the fusion priority hook and fusion pair patches in the same series to make review easier. Since the hook still has limitations, it may be better to review them separately and move each forward independently. For the priority hook patch, would you suggest further revisions, setting it aside to evaluate the pair-fusion pass first, or dropping it? Also, prerequisite patch #2 has been pending for nearly two months. I see that most fusion pair patches have received conditional approval, but still depend on #2 being committed: https://patchwork.sourceware.org/project/gcc/patch/[email protected]/ Could you let me know the review status of #2 and whether it needs any changes? Once it is approved, could we commit #2 and the conditionally approved fusion pair patches first, in dependency order? Thanks, Jin
