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
