[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

Tue Oct 20 00:13:13 PDT 2020

tmsriram abandoned this revision.
tmsriram added a comment.

In D19995#2340941 <https://reviews.llvm.org/D19995#2340941>, @MaskRay wrote:

> @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.

Alright, abandoning.

> ---
>
> 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