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

On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev
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
>       o GlobalConstant
>       o 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.)
>
> A GlobalConstant can either be a definition or a declaration. A 
> definition would look like this:
>
> @foo = globalconst i32 42
This is equivalent to writing "foo = 42" in assembly?
> while a declaration would look like this:
>
> @foo = external globalconst i32
>
> GlobalConstant could also hold a linkage and visibility. Looking at 
> the other attributes that a GlobalValue can hold, many of them do not 
> seem appropriate for GlobalConstant and could potentially be moved to 
> GlobalPointer.
>
> Thoughts?
>
How do you plan to use this?  The concept makes sense, but I've never 
actually seen anyone use symbols this way.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

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

On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev 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.)
>
> A GlobalConstant can either be a definition or a declaration. A definition
> would look like this:
>
> @foo = globalconst i32 42
>
>
> This is equivalent to writing "foo = 42" in assembly?
>
Yes.

>
>
> while a declaration would look like this:
>
> @foo = external globalconst i32
>
> GlobalConstant could also hold a linkage and visibility. Looking at the
> other attributes that a GlobalValue can hold, many of them do not seem
> appropriate for GlobalConstant and could potentially be moved to
> GlobalPointer.
>
> Thoughts?
>
>
> How do you plan to use this?  The concept makes sense, but I've never
> actually seen anyone use symbols this way.
>
I plan to use this as part of the ThinLTO implementation of control flow
integrity. See http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html
for a description of how the design currently works in regular LTO.

If you look at the asm snippets in that design doc, you will see a number
of hardcoded constants -- these constants are calculated at LTO time based
on whole program information. I want the intermediate object files to
depend on the constants so that their values can be substituted in at link
time. In ThinLTO, object files are cached, so if a value changes I want to
avoid invalidating the cache entries that depend on that value.

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

On Mon, Oct 24, 2016 at 1:54 PM Peter Collingbourne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <efriedma at
codeaurora.org>
> wrote:
>
> On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev 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.)
>
> A GlobalConstant can either be a definition or a declaration. A definition
> would look like this:
>
> @foo = globalconst i32 42
>
>
> This is equivalent to writing "foo = 42" in assembly?
>
>
> Yes.
>
>
>
>
> while a declaration would look like this:
>
> @foo = external globalconst i32
>
> GlobalConstant could also hold a linkage and visibility. Looking at the
> other attributes that a GlobalValue can hold, many of them do not seem
> appropriate for GlobalConstant and could potentially be moved to
> GlobalPointer.
>
> Thoughts?
>
>
> How do you plan to use this?  The concept makes sense, but I've never
> actually seen anyone use symbols this way.
>
>
> I plan to use this as part of the ThinLTO implementation of control flow
> integrity. See http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html
> for a description of how the design currently works in regular LTO.
>
> If you look at the asm snippets in that design doc, you will see a number
> of hardcoded constants -- these constants are calculated at LTO time based
> on whole program information. I want the intermediate object files to
> depend on the constants so that their values can be substituted in at link
> time. In ThinLTO, object files are cached, so if a value changes I want to
> avoid invalidating the cache entries that depend on that value.
>
This states the context you want to use these in (CFI with ThinLTO) without
actually stating how you plan to use them within that context. I think the
latter would help motivate specific designs.

Is there a write-up of the imagined CFI+ThinLTO design somewhere that
(concisely) explains the plan?

Maybe you could give some small and easy to understand example usage to
motivate this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161025/5e77b037/attachment.html>

On 24 October 2016 at 16:54, Peter Collingbourne via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <efriedma at
codeaurora.org>
> wrote:
>>
>> On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev 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.)
>>
>> A GlobalConstant can either be a definition or a declaration. A
definition
>> would look like this:
>>
>> @foo = globalconst i32 42
>>
>>
>> This is equivalent to writing "foo = 42" in assembly?
>
>
> Yes.

Back in the day the idea was to use an alias whose ConstantExpr was
just 42. Would that work?

Cheers,
Rafael