This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Relocations to use when eliding plts
- From: Richard Henderson <rth at twiddle dot net>
- To: Rich Felker <dalias at libc dot org>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, "x86-64-abi at googlegroups dot com" <x86-64-abi at googlegroups dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 29 May 2015 08:38:41 -0700
- Subject: Re: Relocations to use when eliding plts
- Authentication-results: sourceware.org; auth=none
- References: <5566232B dot 4080904 at redhat dot com> <CAMe9rOq57A1ksRfn95GTzfc_dFzjPjEzuqswqC8Xu-M62g_Z2g at mail dot gmail dot com> <CAMe9rOpRHqvpJMDSyXk8XrNu04aytCDPnBB03B9A1iSTk=ZhPQ at mail dot gmail dot com> <5567345B dot 5020808 at redhat dot com> <20150528175941 dot GV17573 at brightrain dot aerifal dot cx> <55676146 dot 6040304 at redhat dot com> <20150528192901 dot GW17573 at brightrain dot aerifal dot cx> <20150528194057 dot GS10247 at tucnak dot redhat dot com> <20150528203559 dot GB30226 at brightrain dot aerifal dot cx>
On 05/28/2015 01:36 PM, Rich Felker wrote:
> On Thu, May 28, 2015 at 09:40:57PM +0200, Jakub Jelinek wrote:
>> On Thu, May 28, 2015 at 03:29:02PM -0400, Rich Felker wrote:
>>>> You're not missing anything. But do you want the performance of a
>>>> library to depend on how the main executable is compiled?
>>>
>>> Not directly. But I'd rather be in that situation than have
>>> pessimizations in library codegen to avoid it. I'm worried about cases
>>> where code both loads the address of a function and calls it, such as
>>> this (stupid) example:
>>>
>>> a((void *)a);
>>
>> That can be handled by using just one GOT slot, the non-.got.plt one;
>> only if there are only relocations that guarantee that address equality is
>> not important it would use the faster (*_JUMP_SLOT?) relocations.
>
> How far would this extend, e.g. in the case of LTO or compiling the
> whole library at once?
It depends on how difficult that becomes, I suppose. It's certainly something
that we can look for during LTO.
I did in fact mention this exact point in the original message:
> This does leave open other optimization questions, mostly around weak
> functions. Consider constructs like
>
> if (foo) foo();
>
> Do we, within the compiler, try to CSE GOTPCREL and GOTPLTPCREL, accepting the
> possibility (not certainty) of jump-to-jump but definitely avoiding a separate
> load insn and the latency implied by that?
As a last resort the two can always be unified at static link time, so that
only one got slot is created, and only one runtime relocation exists. At which
point we'd still have two loads in the insn stream. But barring preemption,
the second load will be from cache and cost a single cycle.
So which is less likely, this double-use of a function pointer, or a non-PIE
executable?
r~