Re: [PATCH v3 4/5] RISC-V: Add macro-fusion pair recognition

On 7/22/2026 3:20 AM, Derhaeg, Michiel wrote:
> Hi Jeff, Jin,
>
>> I have not found an ideal way to balance accurate modeling with generic
>> reuse.  Could you suggest what abstraction GCC would prefer in this
>> case, or whether there is a better way to represent these constraint
>> differences between microarchitectures?
> We have encountered the same issue.
> Many of the pre-existing fusion matchers almost fit our needs but
> can't be reused because of differing constraints.
>
> Currently we are trying to reuse as much as possible by
>    A) outlining parts of the matcher that are the same;
>         e.g. reuse the RTL maching but separate destination register checking
>    B) splitting up matchers; e.g; split up BFEXT into one for srli and srai
>
> However, splitting up some fusion matchers to ensure maximum reusability
> can make things needlessly complicated and we just accept the overlap.
Right.  There's a natural tension here and perhaps a misunderstanding 
that what's on the trunk isn't set in stone.

>
> I propose to focus for now on providing generic building blocks (util functions)
> for building matchers and not focus too much on making the RISCV_FUSE_* enum
> itself reusable.
I think those are reasonable building blocks.  And I think at the same 
time we're likely to find meaningful overlap, particularly if we 
consider the cases caught on the trunk as malleable.

>
> Somewhat related: I'm planning on making RA aware of these register constraints
> and then these would need to be separated out anyway. Haven't checked yet
> whether that's actually worth the effort though.
I'm not likely to go too far reviewing RA changes for fusion.  That 
would be Vlad for the most part.  THe work that Artimey did a year or 
two ago really helped these problems.  So my suggestion would be to have 
hard data showing benefits before doing too much to the allocator.

Jeff