[PATCH] D102776: [CG][X86][NFC] Add an option to disable unconditional generation of PLT32 relocations for jmp/call

[Evgeniy via Phabricator via llvm-commits]

ebrevnov added a comment.

In D102776#2772339 <https://reviews.llvm.org/D102776#2772339>, @MaskRay wrote:

> How is it infeasible? PLT32 is moving toward the correct direction and matches most other architectures.
>
> Branch relocation types should be different from PC-relative relocations because the former has less reliance on the semantics. PC-relative relocations can mean address taking operations and can cause issues like canonical PLT entries.

Ok, let me share more details and maybe we can come up with a better solution.

We use LLVM as JIT (Just-In-Time) compiler. In this scenario system dynamic linker is not used and relocations are resolved at compile time before the code get executed. The process has the following 3 phases and resembles classical scheme: "static" linking, remapping and "dynamic" linking (I took "static"&"dynamic"  in quotes because in case of JIT both are done during compilation of a method but compilation itself is done at runtime). All 3 are done by llvm::RuntimeDyld. JITed methods can have dependencies on symbols defined by VM (Virtual Machine) . Such dependencies are ALWAYS satisfied at "dynamic" linking phase (even though addresses of VM provided symbols are known before method compilation they can't be satisfied at the "static" phase which happens before address remapping). Thus we want to avoid unnecessary extra indirection on calls to VM provided symbols which is critical from performance point of view.

Today there is no way to achieve desired behavior. Even though such symbols are marked as "dso_local" PLT32 relocations are still generated for them and PLT stubs are created during "static" linking phase. I wonder if there is any sense to generate PLT relocations for "dso_local" symbols in the first place?

I would expect that I can get desired result by using "-fdirect-access-external-data -f[no-]pie" options but I still see PLT32 relocations generated (https://godbolt.org/z/z3TEsrrMj). Is this expected by the way?

Regarding "PC-relative relocations can mean address taking operations and can cause issues like canonical PLT entries". This is not an issue for us because 1) There is no way to take an address of a method in Java 2) If there was a way we would have canonical PLT entries anyway. In large code model on x86_64 all calls are done through a register and R_X86_64_64 relocations are generated where the register is filled in with a function address.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102776