Reid Kleckner via llvm-dev
2016-Oct-25 21:07 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote:> So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. >No, the value will be discovered at link time, but we want instruction selection to treat the symbol as an immediate, not a GlobalAddress that will receive PIC and GOT treatment. If we use a declaration as you suggest, this example will compile awkwardly: @foo = external global i8 define i64 @addfoo(i64 %v) { %cast = ptrtoint i8* @foo to i64 %v1 = add i64 %v, %cast ret i64 %v1 } The ideal code is: addfoo: leaq foo(%rdi), %rax retq Today we select: addfoo: addq foo at GOTPCREL(%rip), %rdi movq %rdi, %rax retq We could use attributes to try to convince ISel not to form GlobalAddress nodes, but we might also want to consider just adding a new kind of global. Chris's proposal of giving this new globalconst pointer type seems like a reasonable compromise to avoid disturbing the rest of LLVM. The ptrtoint cast will go away when we build MI. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/6b909004/attachment.html>
Rafael Espíndola via llvm-dev
2016-Oct-25 21:48 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
On 25 October 2016 at 17:07, Reid Kleckner <rnk at google.com> wrote:> On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> So, for the declaration, do you expect to know the value? If not just >> a declaration to a GlobalVariable should be sufficient. > > > No, the value will be discovered at link time, but we want instruction > selection to treat the symbol as an immediate, not a GlobalAddress that will > receive PIC and GOT treatment. > > If we use a declaration as you suggest, this example will compile awkwardly: > > @foo = external global i8 > define i64 @addfoo(i64 %v) { > %cast = ptrtoint i8* @foo to i64 > %v1 = add i64 %v, %cast > ret i64 %v1 > } > > The ideal code is: > addfoo: > leaq foo(%rdi), %rax > retq > > Today we select: > addfoo: > addq foo at GOTPCREL(%rip), %rdi > movq %rdi, %rax > retqYou get the code you want with @foo = external hidden global i8 or @foo = external protected global i8 Cheers, Rafael
Reid Kleckner via llvm-dev
2016-Oct-25 21:50 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
On Tue, Oct 25, 2016 at 2:48 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> You get the code you want with > > @foo = external hidden global i8 > > or > > @foo = external protected global i8 >No, that produces this when PIC is on: leaq foo(%rip), %rax addq %rdi, %rax retq We need a way to communicate that foo is really an immediate and not PC-relative. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/37e26594/attachment.html>
Rafael Espíndola via llvm-dev
2016-Oct-25 21:55 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
> You get the code you want with > > @foo = external hidden global i8 > > or > > @foo = external protected global i8Sorry, not quiet. What you get is leaq foo(%rip), %rax Since it is still assuming foo is a position in the file. So yes, we need a way to declare an absolute value. If we can declare it, we may as well use the same construct to define it. I guess the only issue then is that the current implementation of alias becomes even more needlessly generic :-( Cheers, Rafael
Apparently Analagous Threads
- RFC: Absolute or "fixed address" symbols as immediate operands
- RFC: Absolute or "fixed address" symbols as immediate operands
- RFC: Absolute or "fixed address" symbols as immediate operands
- RFC: Absolute or "fixed address" symbols as immediate operands
- RFC: Absolute or "fixed address" symbols as immediate operands