Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

[Michael Matz <matz@suse.de>]

Hi,

On Thu, 30 Apr 2015, Sriraman Tallam wrote:

> We noticed that one of our benchmarks sped-up by ~1% when we eliminated 
> PLT stubs for some of the hot external library functions like memcmp, 
> pow.  The win was from better icache and itlb performance. The main 
> reason was that the PLT stubs had no spatial locality with the 
> call-sites. I have started looking at ways to tell the compiler to 
> eliminate PLT stubs (in-effect inline them) for specified external 
> functions, for x86_64. I have a proposal and a patch and I would like to 
> hear what you think.
> 
> 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.

This can be fixed by Alans idea.

> Further, the newly created GOT entries are fixed up at 
> start-up and do not get lazily bound.

And this can be fixed by some enhancements in the linker and dynamic 
linker.  The idea is to still generate a PLT stub and make its GOT entry 
point to it initially (like a normal got.plt slot).  Then the first 
indirect call will use the address of PLT entry (starting lazy resolution) 
and update the GOT slot with the real address, so further indirect calls 
will directly go to the function.

This requires a new asm marker (and hence new reloc) as normally if 
there's a GOT slot it's filled by the real symbols address, unlike if 
there's only a got.plt slot.  E.g. a

  call *foo@GOTPLT(%rip)

would generate a GOT slot (and fill its address into above call insn), but 
generate a JUMP_SLOT reloc in the final executable, not a GLOB_DAT one.


Ciao,
Michael.