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). > 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? Segher
