On Thu, May 7, 2015 at 11:22 AM, Jeff Law <l...@redhat.com> wrote: > On 05/06/2015 09:24 AM, Alexander Monakov wrote: >> >> On Mon, 4 May 2015, Jeff Law wrote: >>> >>> On 05/04/2015 11:39 AM, Jakub Jelinek wrote: >>>> >>>> On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote: >>>>> >>>>> On 05/04/2015 10:37 AM, Alexander Monakov wrote: >>>>>> >>>>>> This patch introduces option -fno-plt that allows to expand calls that >>>>>> would >>>>>> go via PLT to load the address of the function immediately at call >>>>>> site >>>>>> (which >>>>>> introduces a GOT load). Cover letter explains the motivation for this >>>>>> patch. >>>>>> >>>>>> New option documentation for invoke.texi is missing from the patch; if >>>>>> this is >>>>>> accepted I'll be happy to send a v2 with documentation added. >>>>>> >>>>>> * calls.c (prepare_call_address): Transform PLT call to GOT lookup >>>>>> and >>>>>> indirect call by forcing address into a pseudo with -fno-plt. >>>>>> * common.opt (flag_plt): New option. >>>>> >>>>> OK once you cobble together the invoke.texi changes. >>>> >>>> >>>> Isn't what Michael/Alan suggested better? I mean as/ld/compiler changes >>>> to >>>> inline the plt slot's first part, then lazy binding will work fine. >>> >>> I must have missed Alan/Michael's message. >>> >>> ISTM the win here is that by going through the GOT, you can CSE the GOT >>> reference and possibly get some more register allocation freedom. Is >>> that >>> still the case with Alan/Michael's approach? >> >> >> If the same PLT stubs as today are to be used, it constrains the compiler >> on >> 32-bit x86 and possibly other arches where PLT stubs need GOT pointer in a >> specific register. It's possible to imagine more complex PLT stubs that >> obtain GOT pointer on their own, but in that case you can't let >> optimizations >> such as loop invariant motion move the GOT load away from the call in a >> fashion that could result in PLT stub pointer be reused many times. >> >> Going ahead with this patch now allows anyone to play with no-PLT codegen >> on >> any architecture. As you can see from this series, on x86 it uncovered >> several >> codegen blunders (and fixing those should improve normal codegen as well >> -- so >> everybody wins). >> >> Below is my proposed patch for invoke.texi. Still OK to check in? >> >> * doc/invoke.texi (Code Generation Options): Add -fno-plt. >> ([-fno-plt]): Document. > > We're not changing the defaults, so I think this is fine. Whether or not it > proves useful is still to be determined. >
We should do if we know -z now will be passed to linker and function foo is defined in a shared library. Without the new relocation, we will only know for sure if foo is defined in a shared library when we do LTO. With the new relocation, we can do it for all non-local functions via a compiler switch. -- H.J.
