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

[Peter Collingbourne via llvm-dev]

On Tue, Oct 25, 2016 at 9:09 AM, Chandler Carruth <chandlerc at google.com>
wrote:

> On Mon, Oct 24, 2016 at 10:48 PM Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>>
>> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk>
>> wrote:
>>
>> The specific change I have in mind is to allow !range metadata on
>> GlobalObjects. This would
>> be similar to existing !range metadata, but it would apply to the
>> "address" of the attached GlobalObject, rather than any value loaded from
>> it. Its presence on a GlobalObject would also imply that the address of the
>> GlobalObject is "fixed" at link time.
>>
>>
>> Going back to IR-level representation: here is an alternative
>> representation based on a suggestion from Eli.
>>
>> Introduce a new type of GlobalValue called GlobalConstant. GlobalConstant
>> would fit into the GlobalValue hierarchy like this:
>>
>>    - GlobalValue
>>    - GlobalConstant
>>       - GlobalPointer
>>          - GlobalIndirectSymbol
>>             - GlobalAlias
>>             - GlobalIFunc
>>          - GlobalObject
>>             - Function
>>             - GlobalVariable
>>
>> GlobalValue would no longer be assumed to be of pointer type. The
>> getType() overload that takes a PointerType, as well as getValueType()
>> would be moved down to GlobalPointer. (A nice side benefit of this is that
>> it would help flush out cases where we are unnecessarily depending on
>> global pointee types.)
>>
>>
>> Hi Peter,
>>
>> I agree that it makes sense to introduce a new GlobalConstant IR node for
>> this sort of thing.  That said, have you considered a design where
>> GlobalConstant is still required to be a pointer type?  If you did this,
>> you would end up with a simpler and less invasive design of:
>>
>>    - GlobalValue
>>    - GlobalConstant
>>
>>
>>    - GlobalIndirectSymbol
>>          - GlobalAlias
>>          - GlobalIFunc
>>       - GlobalObject
>>          - Function
>>          - GlobalVariable
>>
>>
>>
>> I think that this would be better for (e.g.) the X86 backend anyway,
>> since global objects can be assigned to specific addresses with linker
>> maps, and thus have small addresses (and this is expressible with the range
>> metadata).  This means that GlobalConstant and other GlobalValues should
>> all be usable in the same places in principle.
>>
>
> If this works, it does seem better. But I can imagine it being hard to
> take the "load" of the global constant and turn it into a direct reference
> to a symbolic immediate operand to an instruction.
>

I think Chris's idea is that you would not use a load but rather a ptrtoint
to access the underlying value.

And it isn't clear that you can assign the "foo" in Peter's example an
> address even with a linker map -- it isn't a global object at all, it is a
> symbolic name for an immediate IIUC? (It's entirely possible I've
> misunderstood either what Peter needs or what you're suggesting, but I'd at
> least like to understand it! =D)
>

I would imagine that the symbolic name could be resolved by the linker with
an absolute symbol (from a linker map or otherwise).

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