<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 24, 2016 at 8:54 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">On Mon, Oct 24, 2016 at 1:54 PM Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_851611661587442275gmail_msg"><div class="gmail_extra gmail-m_851611661587442275gmail_msg"><div class="gmail_quote gmail-m_851611661587442275gmail_msg">On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <span dir="ltr" class="gmail-m_851611661587442275gmail_msg"><<a href="mailto:efriedma@codeaurora.org" class="gmail-m_851611661587442275gmail_msg" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br class="gmail-m_851611661587442275gmail_msg"><blockquote class="gmail_quote gmail-m_851611661587442275gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class="gmail-m_851611661587442275gmail_msg"><span class="gmail-m_851611661587442275m_7345795786505225791gmail- gmail-m_851611661587442275gmail_msg">
<div class="gmail-m_851611661587442275m_7345795786505225791gmail-m_-8905229054276185447moz-cite-prefix gmail-m_851611661587442275gmail_msg">On 10/24/2016 1:07 PM, Peter
Collingbourne via llvm-dev wrote:<br class="gmail-m_851611661587442275gmail_msg">
</div>
<blockquote type="cite" class="gmail-m_851611661587442275gmail_msg">
<div dir="ltr" class="gmail-m_851611661587442275gmail_msg">
<div class="gmail_extra gmail-m_851611661587442275gmail_msg">
<div class="gmail_quote gmail-m_851611661587442275gmail_msg">On Mon, Oct 10, 2016 at 8:12 PM,
Peter Collingbourne <span dir="ltr" class="gmail-m_851611661587442275gmail_msg"><<a href="mailto:peter@pcc.me.uk" class="gmail-m_851611661587442275gmail_msg" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br class="gmail-m_851611661587442275gmail_msg">
<blockquote class="gmail_quote gmail-m_851611661587442275gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="gmail-m_851611661587442275gmail_msg">
<div class="gmail-m_851611661587442275gmail_msg">The specific change I have in mind is to allow
!range metadata on GlobalObjects. This would<br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">
<div class="gmail-m_851611661587442275gmail_msg">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.</div>
</div>
</div>
</blockquote>
<div class="gmail-m_851611661587442275gmail_msg"> </div>
<div class="gmail-m_851611661587442275gmail_msg">Going back to IR-level representation: here is an
alternative representation based on a suggestion from Eli.</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">Introduce a new type of GlobalValue called
GlobalConstant. GlobalConstant would fit into the
GlobalValue hierarchy like this:</div>
<div class="gmail-m_851611661587442275gmail_msg">
<ul class="gmail-m_851611661587442275gmail_msg">
<li class="gmail-m_851611661587442275gmail_msg">GlobalValue<br class="gmail-m_851611661587442275gmail_msg">
</li>
<ul class="gmail-m_851611661587442275gmail_msg">
<li class="gmail-m_851611661587442275gmail_msg">GlobalConstant</li>
<li class="gmail-m_851611661587442275gmail_msg">GlobalPointer</li>
<ul class="gmail-m_851611661587442275gmail_msg">
<li class="gmail-m_851611661587442275gmail_msg">GlobalIndirectSymbol</li>
<ul class="gmail-m_851611661587442275gmail_msg">
<li class="gmail-m_851611661587442275gmail_msg">GlobalAlias</li>
<li class="gmail-m_851611661587442275gmail_msg">GlobalIFunc</li>
</ul>
<li class="gmail-m_851611661587442275gmail_msg">GlobalObject</li>
<ul class="gmail-m_851611661587442275gmail_msg">
<li class="gmail-m_851611661587442275gmail_msg">Function</li>
<li class="gmail-m_851611661587442275gmail_msg">GlobalVariable</li>
</ul>
</ul>
</ul>
</ul>
<div class="gmail-m_851611661587442275gmail_msg">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.)</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">A GlobalConstant can either be a definition or a
declaration. A definition would look like this:</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">@foo = globalconst i32 42</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="gmail-m_851611661587442275gmail_msg"></span>
This is equivalent to writing "foo = 42" in assembly?</div></blockquote><div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_851611661587442275gmail_msg"><div class="gmail_extra gmail-m_851611661587442275gmail_msg"><div class="gmail_quote gmail-m_851611661587442275gmail_msg"><div class="gmail-m_851611661587442275gmail_msg">Yes.</div></div></div></div><div dir="ltr" class="gmail-m_851611661587442275gmail_msg"><div class="gmail_extra gmail-m_851611661587442275gmail_msg"><div class="gmail_quote gmail-m_851611661587442275gmail_msg"><div class="gmail-m_851611661587442275gmail_msg"> </div><blockquote class="gmail_quote gmail-m_851611661587442275gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class="gmail-m_851611661587442275gmail_msg"><span class="gmail-m_851611661587442275m_7345795786505225791gmail- gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
<br class="gmail-m_851611661587442275gmail_msg">
<blockquote type="cite" class="gmail-m_851611661587442275gmail_msg">
<div dir="ltr" class="gmail-m_851611661587442275gmail_msg">
<div class="gmail_extra gmail-m_851611661587442275gmail_msg">
<div class="gmail_quote gmail-m_851611661587442275gmail_msg">
<div class="gmail-m_851611661587442275gmail_msg">
<div class="gmail-m_851611661587442275gmail_msg">while a declaration would look like this:</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">@foo = external globalconst i32</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">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.</div>
<div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg">
</div>
<div class="gmail-m_851611661587442275gmail_msg">Thoughts?</div>
<br class="gmail-m_851611661587442275gmail_msg">
</div>
</div>
</div>
</div>
</blockquote>
<br class="gmail-m_851611661587442275gmail_msg"></span>
How do you plan to use this? The concept makes sense, but I've
never actually seen anyone use symbols this way.</div></blockquote><div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_851611661587442275gmail_msg"><div class="gmail_extra gmail-m_851611661587442275gmail_msg"><div class="gmail_quote gmail-m_851611661587442275gmail_msg"><div class="gmail-m_851611661587442275gmail_msg">I plan to use this as part of the ThinLTO implementation of control flow integrity. See <a href="http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html" class="gmail-m_851611661587442275gmail_msg" target="_blank">http://clang.llvm.org/docs/<wbr>ControlFlowIntegrityDesign.<wbr>html</a> for a description of how the design currently works in regular LTO.</div><div class="gmail-m_851611661587442275gmail_msg"><br class="gmail-m_851611661587442275gmail_msg"></div><div class="gmail-m_851611661587442275gmail_msg">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.</div></div></div></div></blockquote><div><br></div></div></div><div>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.</div><div><br></div><div>Is there a write-up of the imagined CFI+ThinLTO design somewhere that (concisely) explains the plan?</div></div></div></blockquote><div><br></div><div>Here it is: <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/106490.html">http://lists.llvm.org/pipermail/llvm-dev/2016-October/106490.html</a></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>