
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2016, at 10:58 AM, Xinliang David Li <<a href="mailto:davidxl@google.com" class="">davidxl@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Apr 6, 2016 at 9:53 PM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2016, at 9:40 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank" class="">tejohnson@google.com</a>> wrote:</div><br class=""><div class=""><br class=""><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;" class=""><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 class=""> </span><span dir="ltr" class=""><<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>></span><span class=""> </span>wrote:<br class=""><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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Wed, Apr 6, 2016 at 4:53 PM, Mehdi Amini<span class=""> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class=""> </span>wrote:<br class=""><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;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2016, at 4:41 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">1) A function is a leaf function, so it will never import any other functions, and</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">It still may be imported somewhere else right?</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div></span><div class="">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;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">or</div><div class="">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 class=""><br class=""></div><div class="">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 class=""> </span></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Reading this last sentence, it seems exactly the “non-LTO” case?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, basically the point of this proposal is to be able to split the linkage unit into LTO and non-LTO parts.</div><span class=""><div class=""><br class=""></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;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></span><div class="">Yes: we do better optimization on internal function in general.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div><div class="">Inliner is one of the affected optimization -- however this sounds like a matter of tuning to teach inliner about promoted static functions. </div></div></div></blockquote><div><br class=""></div><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>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 class=""><br class=""></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><br class=""></div><div>— </div><div>Mehdi</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""> </div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div class=""> </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;" class=""><div class=""><div class="">Our benchmarks showed that it can really make some difference, and many cases were ThinLTO didn’t perform as well as FullLTO were because of this promotion.</div><div class="">(binary size has never been my concern here)</div></div></div></blockquote><div class=""> <br class=""></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;" class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><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;"><div class="">With this proposal we will need to stick with the current promote everything scheme.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don’t think so: you would need do it only for “internal functions that a leaf and aren’t likely to be imported/inlined”.</div><div class="">That said any function that we emit the binary at compile time instead of link time will contribute to inhibit optimizations for LTO/ThinLTO. The gain in compile time has to be really important to make it worth it.</div><div class="">(Of course the CFI use-case is a totally different tradeoff).</div><div class=""><br class=""></div><div class="">Peter: have you thought about debug info by the way?</div><div class=""><br class=""></div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><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;"><div class=""> <br class=""></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 dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><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;" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I imagine that for some linkers, it may not be possible to deal with this scheme. For example, I did some investigation last year and discovered that I could not use the gold plugin interface to load a native object file if we had already claimed it as an IR file. I wouldn't be surprised to learn that ld64 has similar problems.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I suspect ld64 would need to be update to handle this scheme. Somehow it need to be able to extract the object from the section.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Do you mean the bitcode object? There's already support in LLVM for this (<a href="http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269" target="_blank" class="">http://llvm-cs.pcc.me.uk/lib/Object/IRObjectFile.cpp#269</a>). I suspect the tricky part (which I was unsuccessful at doing with gold) will be convincing the linker that the bitcode object and the regular object are two separate things.</div><span class=""><div class=""><br class=""></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;" class=""><div class=""><div class="">Otherwise this should work, but I suspect the applicability (leaving CFI aside) may not concern that many functions, so I’m not sure about the impact.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I'm also curious about the applicability in the regular ThinLTO case. One thing that may help with applicability is that I suspect that not only leaf functions but also functions that only call (directly or indirectly) functions in the same TU, as well as functions that only make calls via function pointers or vtables may fall under the criteria for non-importing.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">With indirect call profiling the function pointer case should not be a blocker for importing.</div><div class=""><br class=""></div><div class="">Teresa</div><div class=""> </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 dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Peter</div></font></span></div></div></div></blockquote></div><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;" class=""><br clear="all" 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;" class=""><div 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;" class=""><br class=""></div><span 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; float: none; display: inline !important;" class="">--<span class=""> </span></span><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;" class=""><div 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;" class=""><span style="font-family: Times; font-size: inherit;" class=""><table cellspacing="0" cellpadding="0" class=""><tbody class=""><tr style="color: rgb(85, 85, 85); font-family: sans-serif; font-size: small;" class=""><td nowrap="" style="border-top-style: solid; border-top-color: rgb(213, 15, 37); border-top-width: 2px;" class="">Teresa Johnson |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(51, 105, 232); border-top-width: 2px;" class=""> Software Engineer |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(0, 153, 57); border-top-width: 2px;" class=""> <a href="mailto:tejohnson@google.com" target="_blank" class="">tejohnson@google.com</a> |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(238, 178, 17); border-top-width: 2px;" class=""> <a href="tel:408-460-2413" value="+14084602413" target="_blank" class="">408-460-2413</a></td></tr></tbody></table></span></div></div></blockquote></span></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>