Differential D39079
New clang option -fno-plt to avoid PLT for external calls Authored by tmsriram on Oct 18 2017, 9:47 PM.
Details New clang option -fno-plt which avoids the PLT and lazy binding while making external calls. GCC supports -fno-plt, https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00001.html. This patch adds this to clang which marks all externally defined functions with the "nolazybind" attribute. This LLVM patch skips the PLT for calls to these functions, https://reviews.llvm.org/D39065.
Diff Detail Event TimelineComment Actions +1, there should be an -emit-llvm test in clang/test/CodeGen/.
Comment Actions Why again is this a good idea? This is an even worse hack than -Bsymbolic, the latter at least is visible in ELF header without code inspection. This is breaking core premises of ELF. Comment Actions Could you elaborate a bit more on what ELF promises this is breaking? I haven't fully read through D38554 yet. Comment Actions I have no objection to that, although adding a mechanism to fix this (which I imagine would be an attribute tied to the caller, not the callee, would probably end up replacing this mechanism). Comment Actions Let me phrase it differently. What is this patch (and the matching backend PR) supposed to achieve? There are effectively two ways to get rid of PLT entries: Comment Actions It saves the direct jump to the PLT, reducing icache pressure, which is a major cost in some workloads.
Personally, I would like to build LLVM with -Bsymbolic so that we can build LLVM as a DSO and load it from clang without regressing startup time, so I don't see what's so terrible about -Bsymbolic, especially for C++ programs.
What are you talking about? Anyway, LLVM already has an attribute, nonlazybind, and this just provides a flag to apply it to all declarations. It gives the user access to the GOTPCREL relocations that we, and loaders, already support. Comment Actions This patch does 2. According to @tmsriram, clever linkers can turn the indirect call back into a nop+call_pcrel32. If this isn't universal, the user must know what their linker supports. I don't see how it causes performance issues for non-local calls, since the PLT will do a jump through the GOT anyway. Comment Actions
Frankly, in retrospect, ELF's interposition rules (or at least the defaults for those rules), seem suboptimal on several fronts. While breaking them has some unfortunate consistency implications, I don't consider breaking them a bad thing. Comment Actions It also increases the pressure on the branch predictor, so it is not really black and white.
Qt5 tries that. Requires further hacks as the main binary must be compiled as fully position independent code to not run into fun latter. Fun with copy relocations is only part of it.
The loader doesn't see GOTPCREL anymore. It also requires a linker that disassembles instructions, because it can't distinguish between a normal pointer load and a call, to be able to optimize it. Comment Actions Yes, please see this for GOLD linkers: https://sourceware.org/ml/binutils/2016-05/msg00322.html Comment Actions My experiments show that doing this improves performance of some our large workloads by upto 1% and it happens with a reduction in iTLB misses.
The linker can replace indirect calls via GOTPCREL with direct calls, both GOLD and BFD linker support this today. Comment Actions I don't understand this objection. I'm assuming that the PLT stub is an indirect jump through the PLTGOT, not a hotpatched stub that jumps directly to the definition chosen by the loader. This is the ELF model that I'm familiar with, especially since calls to code more than 2GB away generally need to be indirect anyway.
I'm not sure I understand, but this patch isn't introducing copy relocations, to be clear.
Well, yes. The user needs to know that they have an x86-encoding-aware linker, or using this flag is probably going to slow their code down. From my perspective, this is a performance tuning flag, so that's reasonable. Comment Actions Yes, this is correct. A PLT stub for x86_64 looks like this: jmpq *0x2ada(%rip) # 403000 <_GLOBAL_OFFSET_TABLE_+0x18> pushq $0x0 jmpq 400510 <_init+0x30> It has three instructions and the last two are only useful if lazy binding is done. With early binding, the last two instructions is dead code. What this patch does is to take that first instruction and put it at the point where the call is made to the PLT, that's it. Really, with early binding, the PLT stub is a completely redundant piece of code. I can't see how you argue with this.
Comment Actions Correct, so all local calls to the same function go via the same location and share the predication of the indirect jump.
That was in reference to using it for clang. Comment Actions Weigh this against a .plt that is far away from the actual calls, and is causing itlb pressure and is clearly improving itlb behavior by eliminating it on our larger workloads. This is an optimization feature and if this does not improve performance in your case, do not enable it.
Comment Actions I'd also like to highlight that LLVM has many users with different needs. Sometimes we need to "disagree and commit". Flags are one of the primary ways that we have to do that. | ||||||||||||
Remind me what happens when the definition is within the current DSO after linking. I seem to recall that the call through memory is 6 bytes and the direct pcrel call is 5 bytes, and the linker is required to know to rewrite the indirect call to a nop. Is that accurate?