On 2024-07-09 01:49 Jeff Law <jeffreya...@gmail.com> wrote: > > > >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. >
Shall I back port this fix to releases/gcc-14? BR Fei > >Jeff
