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

> 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 <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk
<mailto:peter at pcc.me.uk>> wrote:
>> 
>> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at
pcc.me.uk <mailto: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?

— 
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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/c862a9a8/attachment-0001.html>

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>

> On Oct 25, 2016, at 9:48 AM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> On Tue, Oct 25, 2016 at 9:46 AM Mehdi Amini <mehdi.amini at apple.com
<mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>>
wrote:
>> 
>>> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at
pcc.me.uk <mailto:peter at pcc.me.uk>> wrote:
>>> 
>>> On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at
pcc.me.uk <mailto: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?
To be clear: I just meant it as an extra piece of information. I don’t have a
particular opposition to the “immediate value” solution (that looks pretty smart
and optimal indeed).

— 
Mehdi

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

> 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.
ELF linker implement that too. In the case of lld the target hook is relaxGot.


Cheers,
Rafael