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

[Chandler Carruth via llvm-dev]

On Tue, Oct 25, 2016 at 6:52 PM Peter Collingbourne <peter at pcc.me.uk> wrote:

> On Tue, Oct 25, 2016 at 2:55 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
>
> Sorry, 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
>
>
> So, to summarise the overall consensus on this thread:
> - We should introduce a GlobalConstant class which supports definitions
> and declarations
> - It should derive from GlobalValue
> - No type changes for GlobalValue (i.e. still required to be pointer type)
> - To communicate the range we should use !range metadata and support it on
> GlobalConstant as well as GlobalVariable
>
> Although I am not convinced that this is the right representation I appear
> to be in the minority here, so if this seems reasonable to folks I will go
> ahead and implement it.
>

FWIW, I really dislike this plan.

We are essentially saying we have a GlobalConstant class which is a
pointer, but doesn't point to anything. Instead, it is a pointer that will
have a fixed "constant" address that can be manipulated and/or exploited to
have a very particular integer value via ptrtoint.

I feel like we are going to tremendous lengths to avoid having a
non-pointer global value despite ... having a non-pointer global value. I
would like to understand why it is so problematic to just model this
directly and explicitly in the IR...


>
> Thanks,
> --
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/3aa9dbb6/attachment.html>