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

[Xinliang David Li via llvm-commits]

On Sun, May 8, 2016 at 5:26 PM, John McCall <rjmccall at gmail.com> wrote:

> rjmccall added a comment.
>
> It seems reasonable to me to have an option enabling the use of copy
> relocations for globals, and I agree with David that that option should
> logically be applicable to PIE.  I would also tend to agree with Joerg that
> that option should default to off, even in non-PIC modes, but it's not my
> call.
>
> RE: the performance impact of relying on the linker to optimize accesses:
> it certainly can increase register pressure, but it shouldn't in the most
> common cases where the access sequence ends in putting a new value in a GPR
> anyway (usually either the address of the variable or something loaded from
> it).


Also that linker rewrite may only works for limited simple cases -- after
CSE and instruction scheduling, it can be hard to undo the damage already
made.



>   More importantly, I don't really understand how you can avoid this
> without compiling code assuming that all globals can be copy-relocated,
> since the *compiler* doesn't know whether an external symbol is defined as
> protected or default.  (Unless that's exactly what we're doing — are people
> really this fast-and-loose in ELF land?)
>

Unfortunately it seems that the assumption is made by the compiler (gcc,
clang)  that external symbol has default visibility.


>
> RE: the semantic problems with copy relocations exposing the layout of
> globals: yes, binary compatibility problems usually don't exist when you
> recompile all the dependent code.  I can understand why system maintainers
> wouldn't be thrilled with the idea that certain kinds of updates to system
> libraries can't be made without recompiling the entire user space, though.
>

 If the library write exposes layout of a global in any way to the client
programs, it becomes part of the ABI -- so recompilation is needed
regardless of copyreloc --except for one special case -- the size of the
global remain the same.

David

>
>
> http://reviews.llvm.org/D19995
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160508/fc39a734/attachment.html>