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

[Xinliang David Li via llvm-commits]

In essence, this patch is basically providing a way for user to make
assertion that global declarations are either defined in the main program
or they are truly external (defined DSO), but there is a way to access them
without using GOT via linker magic.  Such assertion is on by default for
non-PIE build. copyreloc is simply an implementation detail.

David

On Mon, May 9, 2016 at 4:04 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160509/86cc83fc/attachment.html>