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
