On 7/8/24 2:39 AM, Fei Gao wrote:
Root cause:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864
Commit above tries in targetm.gen_epilogue () to detect if
there's li a0,0 insn at the end of insn chain, if so, cm.popret
is replaced by cm.popretz and li a0,0 insn is deleted.
Insertion of the generated epilogue sequence
into the insn chain doesn't happen at this moment.
If later shrink-wrap decides NOT to insert the epilogue sequence at the end
of insn chain, then the li a0,0 insn has already been mistakeny removed.
Fix this issue by removing generation of cm.popretz in epilogue,
leaving the assignment to a0 and use insn with cm.popret.
That's likely going to result in some kind of code size regression,
but not a correctness regression.
Optimization can be done in future.
Signed-off-by: Fei Gao <gao...@eswincomputing.com>
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_zcmp_can_use_popretz): Removed.
(riscv_gen_multi_pop_insn): Remove generation of cm.popretz.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rv32e_zcmp.c: Adapt TC.
* gcc.target/riscv/rv32i_zcmp.c: Likewise.
OK.
Has the ESWIN team ever considered doing a bootstrap test of the zcmp*
extensions? ie, turn them all on by default, then build GCC natively on
an rv32 system (or qemu emulated rv32 system)?
I've found that kind of test amazingly helpful through the years to
thoroughly exercise certain changes. In fact, Raphael and I just did
that kind of test on rv32 for stack-clash protection to verify some
degree of correctness on rv32 (the vast majority of our efforts are
focused on rv64). THe only issue we ran into was the linker running out
of address space on the stage3 link, but if you turn off debug symbols
it should bootstrap in rv32.
Jeff
