Hi! On Sat, Mar 14, 2020 at 09:30:02AM +1030, Alan Modra wrote: > On Fri, Mar 13, 2020 at 10:40:38AM -0500, Segher Boessenkool wrote: > > > Using a call-saved register to cache a load out of the PLT looks > > > really silly > > > > Who said anything about using call-saved registers? GCC will usually > > make a stack slot for this, and only use a non-volatile register when > > that is profitable. (I know it is a bit too aggressive with it, but > > that is a generic problem). > > Using a stack slot comes about due to hoisting then running out of > call-saved registers in the loop. Score another reason not to hoist > PLT loads.
LRA can do this directly, without ever using call-saved registers. There are some other passes that can do rematerialisation as well. Not enough yet, but GCC does *not* use non-volatile registers to save values, unless it thinks that is cheaper (which it currently thinks too often, but that is a separate problem). > > > when the inline PLT call is turned back into a direct > > > call by the linker. > > > > Ah, so yeah, for direct calls we do not want this. I was thinking this > > was about indirect calls (via a bctrl that is), dunno how I got that > > misperception. Sorry. > > > > What is this like for indirect calls (at C level)? Does your patch do > > anything to those? > > No effect at all. To put your mind at rest on this point you can > verify quite easily by noticing that UNSPECV_PLT* is only generated in > rs6000_longcall_ref, and calls to that function are conditional on > GET_CODE (func_desc) == SYMBOL_REF. Could you please send a new patch (could be the same patch even) that is easier to review for me? With things like all of the above info in the message (describing the setting, the problem, and the solution). Or should I read the original message another ten times until it clicks? It certainly is possible this matter just is hard to grasp :-/ Thanks in advance, Segher
