[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands

[Peter Collingbourne via llvm-dev]

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>