[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