On 9/2/26 7:26 AM, Jin Ma wrote:
Thank you for the further clarification.
TARGET_SCHED_FUSION_PRIORITY receives only one instruction per call, so
it cannot directly ask whether two specific instructions can fuse. I
am trying to find a better approach that covers these different designs
without duplicating microarchitectural constraints.
Understood. Unfortunate, but that's just how things are.
One simple idea is to split the decision into two levels. The first
level would be used by the priority hook. Since that interface sees
only one instruction at a time, it would determine only whether the
instruction could belong to an enabled fusion operation for the current
tune. This single-instruction eligibility check could be parameterized
by the operation and handle properties already known at that point,
such as load versus store, integer versus floating-point register file,
access mode and width, address form, and extension type. It would not
try to determine relationships between two instructions.
The second level would be used where both candidate instructions are
available. It would call the complete fusion matcher to check actual
pair constraints, such as a common base, adjacent offsets, increasing
or decreasing order, pair alignment, and register relationships. To
avoid maintaining two sets of rules that could drift apart, the
priority classification and final matcher could share the same
operation-specific single-instruction eligibility check, with the full
matcher adding only the constraints between the two instructions.
This would allow Veyron V2, C950, and ARC-V to retain their respective
access-width and other restrictions without applying the restrictions
of one design globally to the others. Existing fusion operations would
be reused where they can express the required behavior, and a new
definition would be added only when an important difference cannot be
represented otherwise. This idea is not final yet. I will continue
checking whether it can support these three designs cleanly and share
the common logic with Michiel's implementation.
I am not sure whether this accurately reflects your suggestion. Do you
have any further comments or guidance?
I think this starts to look at lot like the existing ARM code to convert
adjacent loads into load pairs (and similarly for stores), much like
Andrew also noted. It happens to be the case that I'm starting to
ponder how fusions are going to work for Qualcomm designs going forward
and the ARM approach seems like the best fit.
Essentially we don't have a data dependency to help us identify what
loads (or stores) should be investigated as a potential for load
pairing. With your suggestion I think we end up marking just about
every load in practice on some designs -- at which point, why bother
with the first phase at all.
Jeff
Thanks,
Jin
