On Fri, May 15, 2015 at 1:23 PM, Rich Felker <dal...@libc.org> wrote: > On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote: >> With relax branch in 32-bit, there are 2 cases: >> >> 1. PIC or PIE: We generate >> >> set up EBX >> relax call foo@PLT >> >> It is almost the same as we do now, except for the relax prefix. >> If foo is defined in another shared library or may be preempted, >> linker will generate >> >> call *foo@GOTPLT(%ebx) >> >> If foo turns out local, linker will output >> >> relax call foo > > This does not address the initial and primary motivation for no-plt on > 32-bit: eliminating the awful codegen constraint costs of the > GOT-register (ebx, and equivalent on other targets) ABI for calling > PLT entries. If instead you generated code that sets up an expression > for the GOT slot using arbitrary registers, and relaxed it to a direct > call (possibly rendering the register setup useless), it would be > comparable to the no-plt approach. So for example: > > set up ecx (or whatever register) > relax call *foo@GOT(%ecx) > > and relax to: > > set up ecx (or whatever register; now useless) > relax call foo > > But the no-plt approach is still superior in that the address load > from the GOT can be hoisted out of loops, etc., resulting in something > like: > > call *%esi > > This could be valuable in loops calling a math function repeatedly, > for example. > > Overall I'm still not a fan of the relaxation approach. There are very > few places it would actually help that couldn't already be improved > better with use of visibility, and it can't give codegen as good as > no-plt option.
With no-plt option, compiler has to know if a function is external or may be preempted. If compiler guessed wrong, the generated DSO or executable will always go through indirect branch even though the target is local. With relax branch, the decision is left to linker. Of course, EBX must be used unless we add a new PLT relocation for each register used to to hold GOT base, like relax call foo@PLT_ECX relax call foo@PLT_EDX ... -- H.J.
