On 2024-06-05 14:36 Kito Cheng <kito.ch...@gmail.com> wrote: > >Thanks for fixing this issue, and I am wondering doest it possible to >fix that without introduce target hook? I ask that because...GCC 14 >also has this bug, but I am not sure it's OK to introduce new target >hook for release branch? or would you suggest we just revert patch to >fix that on GCC 14?
If hook is unacceptable in GCC14, I suggest to revert on GCC 14 the following commit. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864 I started fixing this issue by adding changes in mach pass but abandoned it due to the following reasons: 1. more codes to detect location of epilogue in the whole insn list. 2. due to impact by scheduling pass, clear a0 and use a0 insns get reordered, resulting in more codes. 3. data flow analysis is needed, but insn does't have bb info any more, so rescan actually does nothing, which I guess there's some hidden issue in riscv_remove_unneeded_save_restore_calls using dfa. So I came up this hook based patch in prologue and epilogue pass to make the optimization happen as earlier as possible. It ends up with simplicity and clear logic. BR Fei > >On Wed, Jun 5, 2024 at 9:50 AM Fei Gao <gao...@eswincomputing.com> wrote: >> >> The 1st patch adds a hook to allow post processing after epilogue inserted. >> The 2nd one implement the RISC-V hook to solve PR113715. >> >> Fei Gao (2): >> target hooks: allow post processing after epilogue inserted. >> [RISC-V]: fix zcmp popretz [PR113715]. >> >> gcc/config/riscv/riscv.cc | 191 ++++++++++++++------ >> gcc/doc/tm.texi | 5 + >> gcc/doc/tm.texi.in | 2 + >> gcc/function.cc | 2 + >> gcc/hooks.cc | 7 + >> gcc/hooks.h | 1 + >> gcc/target.def | 8 + >> gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c | 56 ++++++ >> 8 files changed, 219 insertions(+), 53 deletions(-) >> >> -- >> 2.17.1 >>
