-msave-restore is a different story; it's only enabled when the user requests, but `-march` describes the capability of the target architecture, not specify the preference of performance or size, which should be determined by -O1~-O3/-Ofast or -Os/-Oz.
On Mon, May 8, 2023 at 4:54 PM Fei Gao <gao...@eswincomputing.com> wrote: > > 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
