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

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Sat May 7 17:39:15 PDT 2016


On Sat, May 7, 2016 at 11:52 AM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sat, May 07, 2016 at 10:58:51AM -0700, Xinliang David Li via
> llvm-commits wrote:
> > To be clear, assuming copyrelocs (support in linker) allows compiler to
> > generate efficient code (speculatively) to access external globals which
> > compiler has no idea where they are going to be defined. For most of the
> > cases, the most of globals end up in the main program, so copyrelocs is
> > only a fallback mechanism in case that is not the case.
>
> I think your reasoning is confusing cause and effect. Copy relocations
> exist, because people didn't want to change things when shared linkage
> was introduced.


What do you mean by 'people didn't want to change things'?

For executable, copy reloc is introduced so that global access without GOT
can be used without requiring text relocation when the reference is truly
external.  Are you saying this is not the case?  History aside, this is
certainly how copyreloc is used today.


> It is a horrible hack and everyone seriously involved
> with ELF acknowledges that it is a horrible hack only comparible to text
> relocatiions


You can certainly feel this way, but making claims about 'everyone involved
..' seems to have no basis and is not relevant here.

David






> There are cleaner ways to address the problem for PIE
> without readding this nightmare. You can mark symbols as hidden. You can
> mark symbols as protected. Both can allow better code generation.





> The
> reduced register pressure is a myth IMO, the difference between a GOT
> load and a direct reference to a symbol for PIC and PIE is being able to
> fold an index computation. That's it.
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160507/63b91494/attachment.html>


More information about the llvm-commits mailing list