[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 19 23:44:05 PDT 2020
MaskRay added a comment.
@tmsriram I think this can be abandoned since we've achieved the optimization with dso_local (dso_local is computed from -mpie-copy-relocations and many other factors),
so we don't need to make the MO_* decision in every backend.
---
clang has -mpie-copy-relocations, which imo is a misnomer.
1. There is no reason that -fno-pic cannot use GOT for external data. The important distinction is executable vs shared object, rather than -fpie vs the other modes.
2. If the external data turns out to be defined in the module, there is no copy relocation. Copy relocation is the result of the worst case but is not guaranteed.
A better name is -m(no-)direct-access-extern https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391#c5 (whether an external default visibility data should be directly accessed (absolute relocation or PC-relative relocation))
(-m may slightly better than -f)
Since @hjl.tools is here...
GCC and binutils should really be fixed for protected data
I had a proposal at https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html
If we adopt such an option, we can replace HAVE_LD_PIE_COPYRELOC with -m(no-)direct-access-extern
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D19995/new/
https://reviews.llvm.org/D19995
More information about the llvm-commits
mailing list