[PATCH] D61613: [LLD][ELF] Add the -z ifunc-noplt option

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 7 20:12:30 PDT 2019


MaskRay requested changes to this revision.
MaskRay added a comment.
This revision now requires changes to proceed.

> FreeBSD makes use of the option when linking x86 kernels, which now make heavy use of ifuncs in hot paths. Without the option, each ifunc results in the generation of a PLT entry, so calls needlessly incur the extra overhead of an indirect jump. With the option, ifunc calls have the same cost as ordinary function calls.

Oh I recall this one and find your efforts to push forward this.

I remember I asked if you got numbers of the improvement and you didn't have an answer then. I still hope you can share the benchmark to justify this is a useful feature. According to my understanding, `-z ifunc-noplt` will introduce many text relocations (a kind of dynamic relocations), that will slow down the dynamic loader. The overhead resolving the text relocation pays off after the function has been called a few number of times. Surely you have hot paths, but many others are cold. The problem of `-z ifunc-noplt` is that it is too large a hammer - it applies to the whole module.

If you extend the usage to userspace applications you may have to tune the runtime code of static linked programs.

If you want a fast memcpy, I wonder why you can't define a global function pointer: `void (*fast_memcpy)(void*,const void*,size_t) __attribute__((visibility("hidden"))) = slow_memcpy;` and initializes it to a fast implementation at runtime.

Compared with the usual ifunc: GOT+PLT, this approach is similar to `-fno-plt`. I'd like to know why you think it doesn't meet your needs and you really need `-z ifunc-noplt`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61613/new/

https://reviews.llvm.org/D61613





More information about the llvm-commits mailing list