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

[Peter Collingbourne via llvm-dev]

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>