On Fri, Mar 13, 2020 at 10:40:38AM -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Mar 13, 2020 at 10:06:01AM +1030, Alan Modra wrote: > > On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote: > > > On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote: > > > > With lazy PLT resolution the first load of a PLT entry may be a value > > > > pointing at a resolver stub. gcc's loop processing can result in the > > > > PLT load in inline PLT calls being hoisted out of a loop in the > > > > mistaken idea that this is an optimisation. It isn't. If the value > > > > hoisted was that for a resolver stub then every call to that function > > > > in the loop will go via the resolver, slowing things down quite > > > > dramatically. > > > > > > > > The PLT really is volatile, so teach gcc about that. > > > > > > It would be nice if we could keep it cached after it has been resolved > > > once, this has potential for regressing performance if we don't? And > > > LD_BIND_NOW should keep working just as fast as it is now, too? > > > > 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. > > 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. -- Alan Modra Australia Development Lab, IBM
