On 2023-05-08 16:05 Kito Cheng <kito.ch...@gmail.com> wrote: > >> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc >> > index 45a63cab9c9..629e5e45cac 100644 >> > --- a/gcc/config/riscv/riscv.cc >> > +++ b/gcc/config/riscv/riscv.cc >> > @@ -5729,7 +5729,8 @@ riscv_get_separate_components (void) >> > >> > if (riscv_use_save_libcall (&cfun->machine->frame) >> > || cfun->machine->interrupt_handler_p >> > - || !cfun->machine->frame.gp_sp_offset.is_constant ()) >> > + || !cfun->machine->frame.gp_sp_offset.is_constant () >> > + || TARGET_ZCMP) >> > return components; >> >> I think this is a bad idea. I have a use case where we use the C >> extensions but still compile for -O2 because we want the code to be >> fast as possible but still having the savings of the C extensions. > >Yeah, agree, so I would prefer to drop this from the patch series.
Zcmp is a little different here than C. C extension is done fully in AS. So we have the code to be fast as possible but still having the savings of the C extensions. Zcmp and shrink-wrap-separate are both done in prologue/epilogue pass and you can only have one switch active to direct sregs save and restore. In my understanding, zcmp push and pop insns seem to be mutually exclusive in functionality to shrink-wrap-separate. It's not expected to see zcmp insns at the begining/end of prologue/epilogue, and also repeated store/load sregs in separate blocks. Same for save and restore, and i guess that's why we have riscv_use_save_libcall (&cfun->machine->frame) check here. BR, Fei > >> Thanks, >> Andrew Pinski
