Re: [PATCH v5 03/18] RISC-V: Add SUB_SEQZ macro-fusion recognition

On 8/13/2026 11:56 PM, Jin Ma wrote:
> Recognize SUB/SUBW followed by SEQZ/SNEZ when the operations have
> the required producer-consumer and destination relationships.  Leave
> the fusion disabled by default.
>
> gcc/ChangeLog:
>
> 	* config/riscv/riscv-fusion.cc (riscv_insn_is_sub_type_p): New
> 	function.
> 	(riscv_fuse_sub_seqz): Likewise.
> 	(riscv_fusion_table): Add RISCV_FUSE_SUB_SEQZ.
> 	* config/riscv/riscv-protos.h (enum riscv_fusion_pairs): Add
> 	RISCV_FUSE_SUB_SEQZ.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/riscv/fusion-sub-seqz-snez.c: New test.
>
> Signed-off-by: Jin Ma <[email protected]>
> ---
>   gcc/config/riscv/riscv-fusion.cc              | 60 +++++++++++++++++
>   gcc/config/riscv/riscv-protos.h               |  1 +
>   .../gcc.target/riscv/fusion-sub-seqz-snez.c   | 66 +++++++++++++++++++
>   3 files changed, 127 insertions(+)
>   create mode 100644 gcc/testsuite/gcc.target/riscv/fusion-sub-seqz-snez.c
>
> diff --git a/gcc/config/riscv/riscv-fusion.cc b/gcc/config/riscv/riscv-fusion.cc
> index 88735b580f1..758e576706f 100644
> --- a/gcc/config/riscv/riscv-fusion.cc
> +++ b/gcc/config/riscv/riscv-fusion.cc
>
>
> +
> +  if (riscv_insn_is_sub_type_p (prev)
> +      && get_attr_type (curr) == TYPE_SLT
> +      && (curr_code == EQ || curr_code == NE)
> +      && riscv_fuse_same_dest_p (prev_set, curr_set, true)
> +      && XEXP (curr_src, 1) == const0_rtx)
> +    return true;
So mostly good.  More of a question than a "please change this".

How convenient are you finding using the insn types to simplify the 
fusion implementation?  I can see the appeal in that you don't have to 
write custom recognition code to match the relevant RTL?  If it's 
helpful and the existing types are a good match, then we can keep doing 
it.  We can also crack existing types into more specific subtypes (as 
long as we go back and add the new insn types to the various pipeline 
models).  So for example, it looks like you use SLT type as the first 
filter, but it matches too many things.  Then you further refine the 
filter by checking the code.  If we end up doing that a lot, breaking 
down the insn type further may be helpful.  We could also consider 
adding new insn attributes specific to fusion.   Anyway, mostly thinking 
out loud about ways we might be able to simplify things.

OK once the prerequisites are in (I'll probably look at #3-#18 first, 
then go back to #2).

jeff