On 9/11/26 3:48 PM, Michiel Derhaeg wrote:
From: Loeka Rogge <[email protected]>
A shNadd whose base is a virtual register prevents the frame offset from
being folded in later, leaving a long sequence behind.
gcc.target/riscv/zba-shNadd-11.c, compiled with -march=rv64i_zba
-mabi=lp64 -O2, produced:
li a5,514
sh3add t0,a5,sp
li a0,-513
sh3add a0,a0,t0
and now produces:
addi a0,sp,8
Regtested on rv32gc and rv64gc.
gcc/ChangeLog:
* config/riscv/riscv.cc (synthesize_add): Do not form shNadd
when the base register is a virtual register.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zba-shNadd-11.c: New test.
Signed-off-by: Michiel Derhaeg <[email protected]>
Signed-off-by: Loeka Rogge <[email protected]>
I'd poked around in this area a few times in recent history, though I
was mostly looking at avoiding FP as an argument to a shadd style insn.
But the motivation is effectively the same -- fp typically turns into
sp+C. In the FP case the transformation happens quite late and there's
precious few opportunities to clean things up afterwards.
However, every time I played with a patch in that space I saw
regressions that I wasn't happy with from a code quality standpoint, so
none of the stuff I played around with went forward.
The other noteworthy thing to be aware of in this space is
fold-mem-offsets knows how to handle shadd style insns. So when these
address arithmetic instructions feed a load/store, f-m-o does tend to
clean things up a bit.
--
Your patch deals with virtuals, which turn into fp+C or sp+C much
earlier. And as your testcase shows, if you're doing address
calculations, but the result is not consumed in a load/store, then
fold-mem-offets won't get a chance to clean things up (one could
legitimately ask if that could be improved, say by starting chains when
the "consumer" is an address computation into a hard register. The goal
being to capture cases where we're passing an address to a child
function or we're returning an address to a caller. But that would be
future work.
I'll push this to the trunk momentarily.
Thanks,
jeff
