<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 3:25 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br><div><blockquote type="cite"><div>On Apr 7, 2016, at 1:21 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Thu, Apr 7, 2016 at 12:52 PM, Mehdi Amini<span> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div><blockquote type="cite"><div>On Apr 7, 2016, at 12:39 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Thu, Apr 7, 2016 at 12:29 PM, Mehdi Amini<span> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div><blockquote type="cite"><div>On Apr 7, 2016, at 11:59 AM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Thu, Apr 7, 2016 at 11:26 AM, Mehdi Amini<span> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Apr 7, 2016, at 10:58 AM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Wed, Apr 6, 2016 at 9:53 PM, Mehdi Amini<span> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Apr 6, 2016, at 9:40 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Wed, Apr 6, 2016 at 5:13 PM, Peter Collingbourne<span> </span><span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini<span> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br><div><div dir="ltr">Hi all,<div><br></div><div>I'd like to propose changes to how we do promotion of global values in ThinLTO. The goal here is to make it possible to pre-compile parts of the translation unit to native code at compile time. For example, if we know that:</div><div><br></div><div>1) A function is a leaf function, so it will never import any other functions, and</div></div></div></blockquote><div><br></div></span><div>It still may be imported somewhere else right?</div><span><br><blockquote type="cite"><div><div dir="ltr"><div>2) The function's instruction count falls above a threshold specified at compile time, so it will never be imported.</div></div></div></blockquote><div><br></div></span><div>It won’t be imported, but unless it is a “leaf” it may import and inline itself.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div dir="ltr"><div>or</div><div>3) The compile-time threshold is zero, so there is no possibility of functions being imported (What's the utility of this? Consider a program transformation that requires whole-program information, such as CFI. During development, the import threshold may be set to zero in order to minimize the incremental link time while still providing the same CFI enforcement that would be used in production builds of the application.)</div><div><br></div><div>then the function's body will not be affected by link-time decisions, and we might as well produce its object code at compile time.<span> </span></div></div></div></blockquote><div><br></div></span><div>Reading this last sentence, it seems exactly the “non-LTO” case?</div></div></div></blockquote><div><br></div></span><div>Yes, basically the point of this proposal is to be able to split the linkage unit into LTO and non-LTO parts.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div dir="ltr"><div>This will also allow the object code to be shared between linkage units (this should hopefully help solve a major scalability problem for Chromium, as that project contains a large number of test binaries based on common libraries).</div><div><br></div><div>This can be done with a change to the intermediate object file format. We can represent object files as native code containing statically compiled functions and global data in the .text,. data, .rodata (etc.) sections, with an .llvmbc section (or, I suppose, "__LLVM, __bitcode" when targeting Mach-O) containing bitcode for functions to be compiled at link time.</div><div><br></div><div>In order to make this work, we need to make sure that references from link-time compiled functions to statically compiled functions work correctly in the case where the statically compiled function has internal linkage. We can do this by promoting every global value with internal linkage, using a hash of the external names (as I mentioned in [1]).</div></div></div></blockquote></span></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>Mehdi - I know you were keen to reduce the amount of promotion. Is that still an issue for you assuming linker GC (dead stripping)?</div></div></div></blockquote><div><br></div></span><div>Yes: we do better optimization on internal function in general.<span> </span></div></div></div></blockquote><div><br></div><div>Inliner is one of the affected optimization -- however this sounds like a matter of tuning to teach inliner about promoted static functions.<span> </span></div></div></div></blockquote><div><br></div></span><div>The inliner compute a tradeoff between pseudo runtime cost and binary size, the existing bonus for static functions is when there is a single call site because it makes the binary increase inexistant (dropping the static after inline). We promote function because we think we are likely to introduce a reference to it somewhere else, so “lying” to the inliner is not necessarily a good idea.</div></div></div></blockquote><div><br></div><div>It is not lying to the inliner. If a static (before promotion) function is a candidate to be inlined in the original defining module, it is probably more likely to inlined in other importing modules where more context is available. In other words, the inliner can apply the same bonus to 'promoted' static functions as if references in other modules will also disappear.  Of course, we can not assume it has single callsite.</div><div><br></div><div>Comdat functions can be handled similarly. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>That said we (actually Bruno did) prototyped it already with somehow good results :)</div><div>I’m not convinced yet that it should be independent of promoted or not promoted though.</div></div></div></div></blockquote><div><br></div><div>Generally true (see the comdat case).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div></div><div>Assuming we solve the inliner issue, then remain the “optimizations other than inliner”. We can probably solve most but I suspect it won’t be “trivial” either.</div></div></div></blockquote><div><br></div><div><br></div><div>Any such optimizations in mind?</div></div></div></blockquote><div><br></div></div></div><div>I don’t have the details, but in short:</div><div><br></div><div>For promoted functions: IPSCCP, dead arg elimination</div><div>For promoted global variables: anything that is impacted somehow by aliasing</div></div></div></blockquote><div><br></div><div>When are you imagining that promotion would happen? If it happens just before codegen (or bitcode emission), it wouldn't inhibit these optimizations, right?</div></div></div></blockquote><div><br></div></div></div><div>For ThinLTO it has to happen before the link-time optimizations, because of cross-module importing.</div></div></div></blockquote><div> </div><div>Are you referring to the fact that these optimizations would be inhibited versus regular LTO, since we cannot internalize? Yes, that does seem like an issue.</div></div></div></blockquote><div><br></div></div></div></div>Yes, this is an issue I'm fighting with currently with ThinLTO.<div>(And I haven't reach the tuning stage yet because I can't nail the infrastructure these days...)</div></div></blockquote><div><br></div><div>Sorry to chime in late here, away from my email most of the day.</div><div><br></div><div>I think the early promotion being proposed by Peter introduces less optimization issues than the missing internalization on globals in ThinLTO. For example, I would anticipate that the inline bonus for static functions with a single callsite would likely provide any intended benefit during the inlining performed in the -O2 -c compile step, and before bitcode/text emission which is presumably when the early promotion would occur. I am not sure about the other places mentioned by Mehdi, I am less familiar with those, but presumably some could/should be done on static functions during a -O2 compile step (e.g. dead argument elimination?).</div><div><br></div><div>For internalization, when I implemented the ThinLTO prototype I had played with applying the single called static function bonus to functions noted as having a single call in the summary (along with linker GC). It sounds like Mehdi/Bruno are also looking at that. I've also not yet had a chance to do optimization tuning on the upstream implementation, hopefully starting that very soon though.</div><div><br></div><div>Teresa</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</div></div>