Bruno Cardoso Lopes
2015-Jan-12 12:00 UTC
[LLVMdev] [PATCH] [RFC][PATCH] Minor opt to access pointers to globals via pcrel GOT entries
+llvmdev to get a broader audience and feedback on the proposal/approach. On Mon, Jan 12, 2015 at 9:51 AM, 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 > > 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. > > Thanks, > > -Bruno > > REPOSITORY > rL LLVM > > http://reviews.llvm.org/D6922 > > Files: > include/llvm/CodeGen/AsmPrinter.h > include/llvm/Target/TargetLoweringObjectFile.h > lib/CodeGen/AsmPrinter/AsmPrinter.cpp > lib/Target/X86/X86TargetObjectFile.cpp > lib/Target/X86/X86TargetObjectFile.h > test/MC/X86/cstexpr-gotpcrel.ll > > EMAIL PREFERENCES > http://reviews.llvm.org/settings/panel/emailpreferences/-- Bruno Cardoso Lopes http://www.brunocardoso.cc