[PATCH] [RFC][PATCH] Minor opt to access pointers to globals via pcrel GOT entries

[Rafael Espíndola]

On 12 January 2015 at 06:51, Bruno Cardoso Lopes <bruno.cardoso at gmail.com>
wrote:

> Hi rafael, grosbach,
>
> Global variables marked with "unnamed_addr" have the following property:
> "...unnamed_addr indicates that the address is not significant, only the
> content".
>
> One potential use of "unnamed_addr" by front-ends is to emit "unnamed_addr
> constant" globals holding pointer initialisers to other global variables.
> For instance, this can be used if the front-end wishes to compute and store
> information against a location with a symbol pointer but doesn't care about
> its address. A more concrete example follows:
>
> @foo = global i32 42
> @proxy = unnamed_addr constant i32* @foo
>
> @delta = global i32 trunc (i64 sub (i64 ptrtoint (i32** @proxy to i64),
>                                    i64 ptrtoint (i32* @delta to i64))
>                           to i32)
>
> Here, @delta holds a data "PC"-relative offset to a pointer of @foo. The
> darwin/x86-64 assembly output for this follows:
>
>  .globl  _foo
> _foo:
>  .long   42
>
>  .globl  _proxy
> _proxy:
>  .quad   _foo
>
>  .globl  _delta
> _delta:
>  .long   _proxy-_delta
>
>
It should also be required that proxy be of a discardable linkage. Using
private seems natural for this.


> I propose a minor optimisation for such cases: given target specific
> support, replace pc-relative accesses to such unnamed_addr global constants
> by a PC relative access to the GOT entry of the final symbol instead.
> Therefore, "delta" would contain a pc relative relocation to foo's GOT
> entry and we avoid the emission of "proxy", yielding the assembly code
> below:
>
>  .globl  _foo
> _foo:
>  .long   42
>
>  .globl  _delta
> _delta:
>  .long   _foo at GOTPCREL+4
>
> There are a couple of advantages of doing this:
> - In situations where all that’s required is that there be some way to get
> the address of an external symbol we save space by not emitting "proxy"
> globals. Front-ends that need to emit a great deal of data containing
> pointers could benefit from this.
> - As a side effect, such IR constructs combined with the proposed opt
> opens a way to represent GOT pcrel relocations by solely using the LLVM IR,
> which is something we currently have no way to express.
>
> Also, this is not MachO specific and can also benefit ELF targets. I've
> attached a patch implementing this simple feature for x86-64/darwin but
> mostly changes are target independent.
>

The general idea makes sense. The logic is that a GOT entry is just a
memory location holding a symbol address. If we have a GV (proxy in the
above example) that is also just a memory location holding a symbol
address, we can replace one with the other.

Why do you have a +4 in the above example?

I have attached a complete example. Running llc on test.ll currently
produces test.s. It could produce test2.s. Linking both test.s and test2.s
with main.c produces a binary that prints 42. The advantage is that test2.o
save a relocation and a memory location.

Note that there is no +4 in test2.s.

I will check the patch itself after lunch.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/99e09d52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ll
Type: application/octet-stream
Size: 523 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/99e09d52/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 720 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/99e09d52/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.s
Type: application/octet-stream
Size: 598 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/99e09d52/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 107 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150123/99e09d52/attachment.c>