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

[Rafael Espíndola via llvm-commits]

On 8 May 2016 at 20:26, 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).  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?)
>
> 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.

I agree with all remarks.

Using this email to note that I think there is a point that was missed
in some messages in this thread:

Using copy relocations is *not* what is making the program faster.

What is making the program faster is that it is not accessing its own
variables with a got. The way copy relocations come into the picture
is that they allow the compiler guess to be wrong in the case of the
main program. If it is, the dynamic linker produces a copy.

So you could get the same (even a bit better maybe) performance by either

* Marking every decl in the main program protected (or hidden if
doesn't take plugins)
* Marking every library decl with dllimport and keeping the default of
assuming externals are local to this DSO.

Copy relocations are just an easy enabler. Another easy one that might
produce close results is building the main program with
-fvisibility=protected. That will mark every definition protected and
avoid some got uses. The linker will hopefully optimize the others.

Cheers,
Rafael