Re: [PATCH v2 2/2] RISC-V: Add instruction fusion (for ventana-vt1)

[Jeff Law <jeffreyalaw@gmail.com>]

On 11/14/22 11:55, Philipp Tomsich wrote:
> On Mon, 14 Nov 2022 at 17:06, Jeff Law <jeffreyalaw@gmail.com> wrote:
>>
>> On 11/13/22 13:48, Philipp Tomsich wrote:
>>> The Ventana VT1 core supports quad-issue and instruction fusion.
>>> This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences
>>> together and adds idiom matcheing for the supported fusion cases.
>>>
>>> gcc/ChangeLog:
>>>
>>>        * config/riscv/riscv.cc (enum riscv_fusion_pairs): Add symbolic
>>>        constants to identify supported fusion patterns.
>>>        (struct riscv_tune_param): Add fusible_op field.
>>>        (riscv_macro_fusion_p): Implement.
>>>        (riscv_fusion_enabled_p): Implement.
>>>        (riscv_macro_fusion_pair_p): Implement and recoginze fusible
>>>        idioms for Ventana VT1.
>>>        (TARGET_SCHED_MACRO_FUSION_P): Point to riscv_macro_fusion_p.
>>>        (TARGET_SCHED_MACRO_FUSION_PAIR_P): Point to riscv_macro_fusion_pair_p.
>> You know the fusion rules for VT1 better than I...  I'm happy to largely
>> defer to you on this.
>>
>> I do wonder if going forward hand matching RTL like this is going to be
>> an unmaintainable mess and whether or not we would be better served
>> using insn attributes to describe instruction fusion.
> I had thought about that, too.
> In the end our team decided to stay away from it for the time being:
> fusion frequently needs to look at second-level properties and whether
> the first instruction's output register is overwritten by the second
> instruction.  So we kept with the same stereotype of idiom-matching
> that is also used for AArch64 today.

Yea, we're still going to have to grub around to get the operands.  But 
we'd know the overall form of the insn and the types of its operands was 
right.  But it's still going to be clunky either way.  My worry with the 
attribute approach is we'll end up with a horrible mess of attributes 
due to multiple fusion implementations and that we'll need to split 
alternatives so that we can tag them more precisely, etc.

It feels like we almost need a DSL to specify this stuff, much like we 
have for scheduling models.


Jeff