On Thu, Jul 23, 2020 at 02:29:00PM -0600, Jeff Law wrote:
> On Thu, 2020-07-23 at 15:19 -0500, Segher Boessenkool wrote:
> > On Thu, Jul 23, 2020 at 01:42:59PM -0600, Jeff Law wrote:
> > > On Thu, 2020-07-23 at 14:25 -0500, Pat Haugen via Gcc-patches wrote:
> > > > Disable -fcaller-saves by default.
> > > > 
> > > > This patch turns off -fcaller-saves by default so that IRA doesn't try
> > > > to use volatile regs for pseudos that are live across a call, which
> > > > would then require LRA to save/restore the reg around the call.
> > > > 2020-07-23  Pat Haugen  <pthau...@linux.ibm.com>
> > > > 
> > > > gcc/
> > > >         * common/config/rs6000/rs6000-common.c
> > > >         (rs6000_option_optimization_table): Turn off -fcaller-saves.
> > > > 
> > > > gcc/testsuite/
> > > >         * gcc.target/powerpc/caller-saves.c: New.
> > > What's driving this change?
> > 
> > Peter noticed IRA allocates stuff to volatile registers while it is life
> > through a call, and then LRA has to correct that, not optimal.
> I can't recall if IRA or LRA handles the need to save them to the stack, but 
> the
> whole point is you can do much better sometimes by saving into the stack with 
> the
> caller-saves algorithm vs just giving up and spilling.

But the only thing this flag influences is what registers IRA allocates,
nothing else, or what am I missing?

> > > IRA will do a cost/benefit analysis to see using call clobbered registers 
> > > like
> > > this is profitable or not.  You're just turning the whole thing off.
> > 
> > '-fcaller-saves'
> >      Enable allocation of values to registers that are clobbered by
> >      function calls, by emitting extra instructions to save and restore
> >      the registers around such calls.  Such allocation is done only when
> >      it seems to result in better code.
> > 
> >      This option is always enabled by default on certain machines,
> >      usually those which have no call-preserved registers to use
> >      instead.

The documentation does not match reality btw, and even contradicts it
for many targets.

> > So, given what Peter saw, the analysis when to do or not do this isn't
> > as good as could be hoped for.
> Sure.  That obviously happens.  When it does the usual response is to dig 
> deeper
> into why, not turn the entire option off.

That is after digging deeper!  Maybe not deep enough, hrm.  Peter?


Segher

Reply via email to