llvm dev - Oct 2016 - RFC: Absolute or "fixed address" symbols as immediate operands

On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> 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.
>
I could go either way on GlobalConstant being a pointer or not. Keeping the
"globals are points" invariant is nice, but making LLVM IR more
accurately
model object file formats is also good.

If I had to choose, I think I would make GlobalConstant a pointer. I don't
think there are many interesting mid-level optimizations that this prevents.

One change I would make is to push the !range metadata into the
GlobalConstant object. The range information is what really unlocks the
interesting ISel optimizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/6e2f352c/attachment.html>

On 26 October 2016 at 12:14, Reid Kleckner <rnk at google.com>
wrote:
> On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>>
>> 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.
>
>
> I could go either way on GlobalConstant being a pointer or not. Keeping the
> "globals are points" invariant is nice, but making LLVM IR more
accurately
> model object file formats is also good.
I would say that requiring a pointer type, specially when there is
only one pointer type in the future, is closer to what the object
format is. In ELF you will get an st_value regardless of it being
absolute of a position in the file. It doesn't really make sense to
have a type that is not at least pointer sized.

Cheers,
Rafael

On Wed, Oct 26, 2016 at 9:21 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 26 October 2016 at 12:14, Reid Kleckner <rnk at google.com> wrote:
> > On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at
pcc.me.uk>
> > wrote:
> >>
> >> 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.
> >
> >
> > I could go either way on GlobalConstant being a pointer or not.
Keeping
> the
> > "globals are points" invariant is nice, but making LLVM IR
more
> accurately
> > model object file formats is also good.
>
> I would say that requiring a pointer type, specially when there is
> only one pointer type in the future, is closer to what the object
> format is. In ELF you will get an st_value regardless of it being
> absolute of a position in the file. It doesn't really make sense to
> have a type that is not at least pointer sized.
>
Acknowledged but that seems a little like saying that because some
architectures only have pointer sized registers we should only support
pointers and pointer sized integers on those architectures.

(Also it appears that COFF's equivalent of st_value is 32-bit even on
64-bit architectures.)

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

On Wed, Oct 26, 2016 at 9:14 AM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Oct 25, 2016 at 6:52 PM, Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>
>> 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.
>>
>
> I could go either way on GlobalConstant being a pointer or not. Keeping
> the "globals are points" invariant is nice, but making LLVM IR
more
> accurately model object file formats is also good.
>
> If I had to choose, I think I would make GlobalConstant a pointer. I
don't
> think there are many interesting mid-level optimizations that this
prevents.
>
I think my concerns are less about inhibiting optimizations than about the
possibility of bad assumptions.

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