On 11/14/22 11:55, Philipp Tomsich wrote:
On Mon, 14 Nov 2022 at 17:06, Jeff Law <jeffreya...@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
