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

[Joerg Sonnenberger via llvm-commits]

joerg added a comment.

In http://reviews.llvm.org/D19995#424345, @rjmccall wrote:

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


Non-PIC use of copy relocations is practically unavoidable and that's not what is under discussion.

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


Evidence for that? In PIC/PIE mode, obtaining the address of a variable is always either a load
(generic case via GOT) or at least an address computation (%rip + offset). Even for the second case,
I don't think full folding without scratch register is a very common case.

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


The (sane) default behavior for PIC and PIE code is to access external symbols with default visibility
via the GOT. I find it perfectly reasonable to request symbols to be marked as protected if they should
still be externally visible AND get optimized. It only really matters semantically when also using --export-dynamic
anyway.

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


Yes, this is exactly one of the core reasons why I am adamant against supporting copy relocations for PIE.
It forces real performance degradations for library interfaces, that often have a far more measurable impact.


http://reviews.llvm.org/D19995