This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=
- From: Xinliang David Li <davidxl at google dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Sriraman Tallam <tmsriram at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Fri, 1 May 2015 09:19:06 -0700
- Subject: Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmxC4KQSc5EWiux7syOj8+ghs_LY8zY-D4-Wjp+ZhHiDuw at mail dot gmail dot com> <87r3r0mjec dot fsf at tassilo dot jf dot intel dot com>
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen <andi@firstfloor.org> wrote:
> Sriraman Tallam <tmsriram@google.com> writes:
>>
>> This comes with caveats. This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if
>> a function is "truly extern" (defined in a shared library). If a
>> function is not truly extern(ends up defined in the final executable),
>> then calling it indirectly is a performance penalty as it could have
>> been a direct call. Further, the newly created GOT entries are fixed
>> up at start-up and do not get lazily bound.
>
> This means you need to make it depend on -fno-semantic-interposition ?
>
>> Given this, I propose adding a new option called
>> -fno-plt=<function-name> to the compiler. This tells the compiler
>> that we know that the function is truly extern and we want the
>> indirect call only for these call-sites. I have attached a patch that
>> adds -fno-plt= to GCC. Any number of "-fno-plt=" can be specified and
>> all call-sites corresponding to these named functions will be done
>> indirectly using the mechanism described above without the use of a
>> PLT stub.
>
> The argument seems awkward. The command line may get very long.
> Better an attribute?
They are complementary. Perhaps another option like linker's
--dynamic-list=<> that can take a file specifying the list of symbols.
>
> Longer term it would be probably better to support it properly
> in the linker.
>
Linker solution has its own downside -- it require reserving more
space conservatively for many callsites which end up being direct
calls.
David
> -Andi
>
> --
> ak@linux.intel.com -- Speaking for myself only