[PATCH] D157020: [WIP][lld/ELF] Don't relax R_X86_64_(REX_)GOTPCRELX when offset is too far

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 3 12:02:27 PDT 2023


aeubanks added a comment.

In D157020#4558475 <https://reviews.llvm.org/D157020#4558475>, @MaskRay wrote:

> This should state the motication, which is likely to alleviate relocation overflow pressure.
>
>> On x86-64, linkers optimize some GOT-indirect instructions (R_X86_64_REX_GOTPCRELX; e.g. movq var at GOTPCREL(%rip), %rax) to PC-relative instructions. The distance between a code section and .got is usually smaller than The distance between a code section and .data/.bss. ld.lld's one-pass relocation scanning scheme has a limitation: if it decides to suppress a GOT entry and it turns out that optimizing the instruction will lead to relocation overflow, the decision cannot be reverted. It should be easy to work around the issue with -Wl,--no-relax.

I wouldn't say this is to "alleviate relocation overflow pressure", I'd say this is straight up just a bug fix. The linker shouldn't be doing this optimization if it breaks linking right?

> However, I'm not sure adding another relocation scanning pass for this purpose is a good idea. It's quite a bit of code targeted with very specific workloads where `-Wl,--no-relax` can be used instead. Our relocation scanning is more complex than mold and makes us slower. I'm fairly concerned of more relocation passes.

Perhaps we can avoid the extra relocation scan in cases where we detect that the max offset is under 2^31?
I'm pretty `--no-relax` will be unacceptable performance-wise for accessing extern globals.

> (Another minor thing is that I think our relocation scanning really needs overhaul to improve performance. This tricky case would add another item to account for when we do the refactoring.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157020



More information about the llvm-commits mailing list