Relocations to use when eliding plts

Richard Henderson
Fri May 29 15:38:00 GMT 2015

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 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


More information about the Gcc mailing list