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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 25 09:09:09 PDT 2016


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.

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)

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/771fe984/attachment.html>


More information about the llvm-dev mailing list