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

[Chandler Carruth via llvm-dev]

On Tue, Oct 25, 2016 at 9:46 AM Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Oct 25, 2016, at 9:09 AM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>
>
> The linker “could" do it I think. For example ld64 is pattern matching to
> "optimize away” load from the GOT when possible, replacing then with nop
> and propagating the constant address.
>
> It is still not perfect, as a register has to be used sometimes, and the
> nop will still be there taking space. But that may be enough for this use
> case?
>

For CFI, I think that would be a pretty frustrating overhead to pay for,
and would require linker changes on at least some platforms.

Is there a reason to not directly support symbolic names for immediate
values?


>
> —
> Mehdi
>
>
>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/81e3ac3a/attachment.html>