<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 January 2015 at 06:51, Bruno Cardoso Lopes <span dir="ltr"><<a href="mailto:bruno.cardoso@gmail.com" target="_blank">bruno.cardoso@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi rafael, grosbach,<br>
<br>
Global variables marked with "unnamed_addr" have the following property: "...unnamed_addr indicates that the address is not significant, only the content".<br>
<br>
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:<br>
<br>
@foo = global i32 42<br>
@proxy = unnamed_addr constant i32* @foo<br>
<br>
@delta = global i32 trunc (i64 sub (i64 ptrtoint (i32** @proxy to i64),<br>
                                   i64 ptrtoint (i32* @delta to i64))<br>
                          to i32)<br>
<br>
Here, @delta holds a data "PC"-relative offset to a pointer of @foo. The darwin/x86-64 assembly output for this follows:<br>
<br>
 .globl  _foo<br>
_foo:<br>
 .long   42<br>
<br>
 .globl  _proxy<br>
_proxy:<br>
 .quad   _foo<br>
<br>
 .globl  _delta<br>
_delta:<br>
 .long   _proxy-_delta<br>
<br></blockquote><div><br></div><div>It should also be required that proxy be of a discardable linkage. Using private seems natural for this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
 .globl  _foo<br>
_foo:<br>
 .long   42<br>
<br>
 .globl  _delta<br>
_delta:<br>
 .long   _foo@GOTPCREL+4<br>
<br>
There are a couple of advantages of doing this:<br>
- 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.<br>
- 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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Why do you have a +4 in the above example?</div><div><br></div><div>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.</div><div><br></div><div>Note that there is no +4 in test2.s.</div><div><br></div><div>I will check the patch itself after lunch.</div><div><br></div><div>Cheers,</div><div>Rafael</div><div><br></div><div><br></div><div><br></div></div></div></div>