Friedman, Eli via llvm-dev
2016-Oct-24 20:36 UTC
[llvm-dev] 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 42This 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>
Peter Collingbourne via llvm-dev
2016-Oct-24 20:54 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
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>
Chandler Carruth via llvm-dev
2016-Oct-25 03:54 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
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>
Rafael EspĂndola via llvm-dev
2016-Oct-25 12:43 UTC
[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands
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