<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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail-m_-3137680957533894994m_-8210981312489305036h5"><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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">On Mon, Oct 24, 2016 at 1:36 PM, Friedman, Eli <span dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><<a href="mailto:efriedma@codeaurora.org" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><blockquote class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><span class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122m_7345795786505225791gmail- gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122m_7345795786505225791gmail-m_-8905229054276185447moz-cite-prefix gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">On 10/24/2016 1:07 PM, Peter
Collingbourne via llvm-dev wrote:<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<blockquote type="cite" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">On Mon, Oct 10, 2016 at 8:12 PM,
Peter Collingbourne <span dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><<a href="mailto:peter@pcc.me.uk" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<blockquote class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">The specific change I have in mind is to allow
!range metadata on GlobalObjects. This would<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"> </div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">Going back to IR-level representation: here is an
alternative representation based on a suggestion from Eli.</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">Introduce a new type of GlobalValue called
GlobalConstant. GlobalConstant would fit into the
GlobalValue hierarchy like this:</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<ul class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalValue<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</li>
<ul class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalConstant</li>
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalPointer</li>
<ul class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalIndirectSymbol</li>
<ul class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalAlias</li>
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalIFunc</li>
</ul>
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalObject</li>
<ul class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">Function</li>
<li class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">GlobalVariable</li>
</ul>
</ul>
</ul>
</ul>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">A GlobalConstant can either be a definition or a
declaration. A definition would look like this:</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">@foo = globalconst i32 42</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"></span>
This is equivalent to writing "foo = 42" in assembly?</div></blockquote><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">Yes.</div></div></div></div><div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"> </div><blockquote class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><span class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122m_7345795786505225791gmail- gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<blockquote type="cite" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">while a declaration would look like this:</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">@foo = external globalconst i32</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
<div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">Thoughts?</div>
<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg">
</div>
</div>
</div>
</div>
</blockquote>
<br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"></div></div></div></div><div dir="ltr" class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_extra gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail_quote gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg" target="_blank">http://clang.llvm.org/docs/Con<wbr>trolFlowIntegrityDesign.html</a> for a description of how the design currently works in regular LTO.</div><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"><br class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_msg"></div><div class="gmail-m_-3137680957533894994m_-8210981312489305036m_3563400705284955122gmail_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>Not just yet, at least not regarding the part which requires constants. I will send that to the list separately.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Maybe you could give some small and easy to understand example usage to motivate this?</div></div></div>
</blockquote></div><br>Sure. Suppose you have two modules:</div><div class="gmail_extra"><br></div><div class="gmail_extra">m1.ll:</div><div class="gmail_extra"><br></div><div class="gmail_extra">@foo = globalconst i8 1</div><div class="gmail_extra"><br></div><div class="gmail_extra">m2.ll:</div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">@foo = external globalconst i8</div><div class="gmail_extra"><br></div><div class="gmail_extra">define i32 @f(i32 %x) {</div><div class="gmail_extra"> %1 = lshr i32 %x, zext i8 @foo to i32</div><div class="gmail_extra"> %2 = and i32 %1, 1</div><div class="gmail_extra"> ret i32 %2</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><div>These produce a pair of object files which when linked together produces a function f that selects bit "foo" of its argument. I can link m2.ll with some other object file with some other definition of foo to produce a function f that selects some other bit. That other object file can be produced independently of m2, which means that I can change the selected bit without needing to recompile m2.</div><div><br></div><div>How is this more useful than a regular constant GlobalVariable? Let's look at what the asm code for m2.ll would hypothetically look like:</div><div><br></div><div>.globl f</div><div>f:</div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>shrl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>$foo, %edi</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>andl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>$1, %edi</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>movl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>%edi, %eax</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>retq</div></div><div><br></div><div>Compare this to the case where foo is a regular GlobalVariable which we load from in f:</div><div><br></div><div>f:</div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>movb<span class="gmail-Apple-tab-span" style="white-space:pre"> foo</span>(%rip), %cl</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>shrl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>%cl, %edi</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>andl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>$1, %edi</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>movl<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>%edi, %eax</div></div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> retq</span><br></div><div><span class="gmail-Apple-tab-span" style="white-space:pre"><br></span></div><div>As you can see there is a clear win in code size and register pressure.</div><div><br></div><div>Thanks,</div>-- <br><div class="gmail-m_-3137680957533894994m_-8210981312489305036gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>