llvm dev - Oct 2016 - 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>

>> 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

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>

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>