Re: [PATCH v5 11/18] RISC-V: Generalize LDPREINCREMENT macro-fusion recognition

On 8/14/2026 12:00 AM, Jin Ma wrote:
> Allow LDPREINCREMENT to match non-word ADDI-type in-place address
> updates followed by scalar integer or floating-point loads.  Support
> register-plus-offset and LO_SUM addresses, self moves, and either
> load-destination relationship.
>
> Put the common pre/post-index load/store constraints in a
> parameterized helper for later fusion rules.
>
> gcc/ChangeLog:
>
> 	* config/riscv/riscv-fusion.cc (riscv_fuse_indexed_mem_p): New
> 	function.
> 	(riscv_fuse_ldpreincrement): Use it and accept scalar integer or
> 	floating-point loads.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/riscv/fusion-preindex-load.c: New test.
> 	* gcc.target/riscv/fusion-preindex-load-rtl.c: Likewise.
>
> Signed-off-by: Jin Ma <[email protected]>
So I think the question we should try to answer is whether or not we 
want two fusion styles or just one.

The Veryon V2 design doesn't try to fuse the FP case, at least not with 
traditional DEC based pairwise fusion and that design requires the 
destination registers to match for the integer cases it supports.  My 
recollection is this fusion scenario wasn't terribly effective on that 
design.  So if someone was to want to see Veyron V2 support in GCC I'd 
recommend they simply not enable this fusion. The gains were minimal at 
best and the over-matching runs the risk of harming performance.

If we were to find other designs that behaved more like the Veyron V2, 
that's the point where we'd probably look at breaking this down into two 
variants.

So with that this is OK for the trunk once the prereqs are approved.

jeff