This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Expand PIC calls without PLT with -fno-plt
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Rich Felker <dalias at libc dot org>
- Date: Thu, 7 May 2015 12:13:52 -0700
- Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt
- Authentication-results: sourceware.org; auth=none
- References: <1430757479-14241-1-git-send-email-amonakov at ispras dot ru> <1430757479-14241-6-git-send-email-amonakov at ispras dot ru> <5547AD8D dot 9080806 at redhat dot com> <20150504173955 dot GE1751 at tucnak dot redhat dot com> <5547AF7C dot 9030500 at redhat dot com> <alpine dot LNX dot 2 dot 11 dot 1505061730460 dot 22867 at monopod dot intra dot ispras dot ru> <554BAD59 dot 50107 at redhat dot com>
On Thu, May 7, 2015 at 11:22 AM, Jeff Law <law@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.