tmsriram added a comment. In https://reviews.llvm.org/D39079#905519, @joerg wrote:
> In https://reviews.llvm.org/D39079#905468, @rnk wrote: > > > In https://reviews.llvm.org/D39079#905454, @joerg wrote: > > > > > It also increases the pressure on the branch predictor, so it is not > > > really black and white. > > > > > > 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. > > > Correct, so all local calls to the same function go via the same location and > share the predication of the indirect jump. 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. > > >>> 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. >> >> I'm not sure I understand, but this patch isn't introducing copy >> relocations, to be clear. > > That was in reference to using it for clang. https://reviews.llvm.org/D39079 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
