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

  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.

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
---

Changes in v2:
- Update fusion patterns and catch some missing idioms/fusion pairs.

 gcc/config/riscv/riscv.cc | 219 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 219 insertions(+)
  

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.



>
> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
> ---
>
> Changes in v2:
> - Update fusion patterns and catch some missing idioms/fusion pairs.
>
>   gcc/config/riscv/riscv.cc | 219 ++++++++++++++++++++++++++++++++++++++
>   1 file changed, 219 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 31d651f8744..43ba520885c 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
>
> +static bool
> +riscv_macro_fusion_pair_p (rtx_insn *prev, rtx_insn *curr)
> +{
> +  rtx prev_set = single_set (prev);
> +  rtx curr_set = single_set (curr);
> +  /* prev and curr are simple SET insns i.e. no flag setting or branching.  */
> +  bool simple_sets_p = prev_set && curr_set && !any_condjump_p (curr);
> +
> +  if (!riscv_macro_fusion_p ())
> +    return false;
> +
> +  if (simple_sets_p && (riscv_fusion_enabled_p (RISCV_FUSE_ZEXTW) ||
> +			riscv_fusion_enabled_p (RISCV_FUSE_ZEXTH)))

Formatting nit.  Bring the && down to a new line and if you still need a 
line break for the "||",  then the "||" should be on a new line as 
well.  Something like this...


if (simple_sets_p
       && (riscv_fusion_enabled_p (RISCV_FUSE_ZEXTW

           || riscv_fusion_enabled_p (RISCV_FUSE_ZEXTH)))


> +	  && REGNO (XEXP (SET_SRC (curr_set), 0)) == REGNO(SET_DEST (curr_set))

Space before open paren on this line.


>
> +	  && (( INTVAL (XEXP (SET_SRC (curr_set), 1)) == 32
> +		&& riscv_fusion_enabled_p(RISCV_FUSE_ZEXTW) )
> +	      || ( INTVAL (XEXP (SET_SRC (curr_set), 1)) < 32
> +		   && riscv_fusion_enabled_p(RISCV_FUSE_ZEXTWS))))

Extraneous spaces after the open parens before INTVALs above.


> +	  && REGNO (XEXP (SET_SRC (curr_set), 0)) == REGNO(SET_DEST (curr_set))

Missing whitespace before open paren on this line.


OK with the nits fixed.


Jeff
  

On Mon, Nov 14, 2022 at 09:06:10AM -0700, Jeff Law via Gcc-patches 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

s/recoginze/recognize/

> > 	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.

	Jakub
  

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.

That said, both the RISC-V and the AArch64 implementations of this are
on my list of things to refactor in a quiet hour.

>
>
>
> >
> > Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
> > ---
> >
> > Changes in v2:
> > - Update fusion patterns and catch some missing idioms/fusion pairs.
> >
> >   gcc/config/riscv/riscv.cc | 219 ++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 219 insertions(+)
> >
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 31d651f8744..43ba520885c 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> >
> > +static bool
> > +riscv_macro_fusion_pair_p (rtx_insn *prev, rtx_insn *curr)
> > +{
> > +  rtx prev_set = single_set (prev);
> > +  rtx curr_set = single_set (curr);
> > +  /* prev and curr are simple SET insns i.e. no flag setting or branching.  */
> > +  bool simple_sets_p = prev_set && curr_set && !any_condjump_p (curr);
> > +
> > +  if (!riscv_macro_fusion_p ())
> > +    return false;
> > +
> > +  if (simple_sets_p && (riscv_fusion_enabled_p (RISCV_FUSE_ZEXTW) ||
> > +                     riscv_fusion_enabled_p (RISCV_FUSE_ZEXTH)))
>
> Formatting nit.  Bring the && down to a new line and if you still need a
> line break for the "||",  then the "||" should be on a new line as
> well.  Something like this...
>
>
> if (simple_sets_p
>        && (riscv_fusion_enabled_p (RISCV_FUSE_ZEXTW
>
>            || riscv_fusion_enabled_p (RISCV_FUSE_ZEXTH)))
>
>
> > +       && REGNO (XEXP (SET_SRC (curr_set), 0)) == REGNO(SET_DEST (curr_set))
>
> Space before open paren on this line.
>
>
> >
> > +       && (( INTVAL (XEXP (SET_SRC (curr_set), 1)) == 32
> > +             && riscv_fusion_enabled_p(RISCV_FUSE_ZEXTW) )
> > +           || ( INTVAL (XEXP (SET_SRC (curr_set), 1)) < 32
> > +                && riscv_fusion_enabled_p(RISCV_FUSE_ZEXTWS))))
>
> Extraneous spaces after the open parens before INTVALs above.
>
>
> > +       && REGNO (XEXP (SET_SRC (curr_set), 0)) == REGNO(SET_DEST (curr_set))
>
> Missing whitespace before open paren on this line.
>
>
> OK with the nits fixed.

Applied to master with these fixes (and a fix for the typo in the
commit message that Jakub spotted).
Thanks!

Philipp.
  

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