Peter Collingbourne via llvm-dev
2016-Oct-25 18:29 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
On Tue, Oct 25, 2016 at 5:49 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> >>> @foo = globalconst i32 42 > >>> > >>> > >>> This is equivalent to writing "foo = 42" in assembly? > >> > >> > >> Yes. > > > > > > Back in the day the idea was to use an alias whose ConstantExpr was > > just 42. Would that work? > > In fact, it already works: > > @foo = alias i64, inttoptr (i64 42 to i64*) > > produces > > foo = 42 > > Cheers, > Rafael >Right, I should have brought up that we can already use aliases for definitions -- that's what I've been using in my prototype. What I think we need to decide on here is a representation for declarations. From that, I think our representation for definitions should be clear. For example, I think that if we decide to require GlobalConstant to have a pointer type, it may be reasonable to use it only for declarations and to use GlobalAlias for definitions. This I think would be analogous to the current state where a GlobalAlias can be referenced by either a Function or a GlobalVariable. Thanks, -- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/d1961833/attachment.html>
Rafael Espíndola via llvm-dev
2016-Oct-25 20:48 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
>> In fact, it already works: >> >> @foo = alias i64, inttoptr (i64 42 to i64*) >> >> produces >> >> foo = 42 >> >> Cheers, >> Rafael > > > Right, I should have brought up that we can already use aliases for > definitions -- that's what I've been using in my prototype. What I think we > need to decide on here is a representation for declarations. From that, I > think our representation for definitions should be clear. For example, I > think that if we decide to require GlobalConstant to have a pointer type, it > may be reasonable to use it only for declarations and to use GlobalAlias for > definitions. This I think would be analogous to the current state where a > GlobalAlias can be referenced by either a Function or a GlobalVariable.So, for the declaration, do you expect to know the value? If not just a declaration to a GlobalVariable should be sufficient. Otherwise, can you use an available_externally alias? Since we are talking about the class hierarchy, it is somewhat annoying that there are function declaration and variable declarations. At the object level, there is only undefined symbols. Cheers, Rafael
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>
Peter Collingbourne via llvm-dev
2016-Oct-25 21:14 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> >> In fact, it already works: > >> > >> @foo = alias i64, inttoptr (i64 42 to i64*) > >> > >> produces > >> > >> foo = 42 > >> > >> Cheers, > >> Rafael > > > > > > Right, I should have brought up that we can already use aliases for > > definitions -- that's what I've been using in my prototype. What I think > we > > need to decide on here is a representation for declarations. From that, I > > think our representation for definitions should be clear. For example, I > > think that if we decide to require GlobalConstant to have a pointer > type, it > > may be reasonable to use it only for declarations and to use GlobalAlias > for > > definitions. This I think would be analogous to the current state where a > > GlobalAlias can be referenced by either a Function or a GlobalVariable. > > So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. >Not on its own. We need some way to distinguish absolute symbols from regular symbols so that we know to create absolute relocations instead of PC-relative relocations in PIC mode. That's what I was doing in D25878 with !range metadata. What I found odd about that representation is that we would have a global variable with metadata that says "by the way, this isn't actually a global variable". So I wanted to see if there was some representational fix for that. Otherwise, can you use an available_externally alias?> > Since we are talking about the class hierarchy, it is somewhat > annoying that there are function declaration and variable > declarations. At the object level, there is only undefined symbols. >Although that is strange, I think the point is to allow attributes on the declaration that allow optimizers to assume things about the pointer (e.g. is it a readnone function). You could imagine some separate ExternalSymbol global that is a sort of a discriminated union of the function/global attributes, but at that point there doesn't seem to be a benefit over the specialized function/global representations. I imagine that the "range" of the globalconst would be one such attribute in this case. Thanks, -- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/cd4624d5/attachment.html>