
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 May 3, 2016, at 10:25 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" 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_extra"><div class="gmail_quote">On Tue, May 3, 2016 at 10:04 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 May 3, 2016, at 10:01 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</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 Tue, May 3, 2016 at 9:01 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=""><blockquote type="cite" class=""><span 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=""></span><span 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 class="">2) The function's instruction count falls above a threshold specified at compile time, so it will never be imported.</div><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. 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></div></span></blockquote><div class=""><br class=""></div><div class="">I was wondering why can't the "precompiled" function be embedded in the IR instead of the bitcode embedded in the object file? </div><div class="">The codegen would still emit a single object file out of this IR file that contains the code for the IR and the precompiled function.</div><div class=""><br class=""></div><div class="">It seems to me that this way the scheme would work with any existing existing LTO implementation.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You'd still have the same problem. No matter whether you put the native object inside the IR file or vice versa, you still have a file containing a native object and some IR. That's the scenario that I found that the gold plugin interface wouldn't support.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">It is not clear to me why it is a problem for gold: it does not need to know that the IR file contains some native precompiled code: it only need to know that this is an "LLVM file", that will be passed to LLVM for LTO and it will get a single object file in return.</div><div class="">Can you elaborate why the linker need to know beforehand and differentiate?</div></div></div></blockquote><div class=""><br class=""></div><div class="">(There wouldn't just be one object file, there would be N native objects and 1 (or N if ThinLTO) combined LTO objects.)</div></div></div></div></div></blockquote><div><br class=""></div><div>No really, that's not what I described. I described a mode where even llc would be able to process this input IR file with an embedded precompiled function and spit out a single object file.</div><div>Conceptually, it should be similar to a naked IR function with inline assembly for instance, or module level inline assembly, i.e. totally transparent to the linker.</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">In principle, it doesn't need to know. In practice, I found that in my prototype I couldn't persuade gold to accept what I was doing without giving undefined symbol errors.</div><div class=""><br class=""></div><div class="">I suppose I could have debugged it further, but I couldn't justify spending more time on it, since the projects I care about are interested in switching to lld for other reasons.</div><div class=""><br class=""></div><div class="">Peter</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=""><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div>-- </font></span></div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span><span class=""><div 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=""><br class=""></div><div class="">Supporting IR embedded in a native object section inside a linker should be pretty trivial, if you control the linker. My prototype implementation in lld is about 10 lines of code.<br class=""></div><div class=""><br class=""></div><div class="">Peter</div><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=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- </div><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 dir="ltr" class=""><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 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 class=""><br class=""></div><div class="">In cases where we completely control the linker (e.g. lld), we can easily support this scheme, as the linker can directly do whatever it wants. But for linkers that cannot support this, I suggest that we promote consistently under ThinLTO rather than having different promotion schemes for different linkers, in order to reduce overall complexity.</div><div class=""><div class=""><br class=""></div><div class="">Thanks for your feedback!</div><div class=""><br class=""></div><div class="">Thanks,</div>--<span class=""> </span><br class=""><div class=""><div dir="ltr" class="">-- <div class="">Peter</div><div class=""><br class=""></div><div class="">[1] <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-April/098062.html" target="_blank" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-April/098062.html</a></div></div></div></div></div></div></blockquote></span></div><br class=""></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=""><div dir="ltr" class="">-- <div class="">Peter</div></div></div></div></blockquote></div><br class=""></span></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature"><div dir="ltr" class="">-- <div class="">Peter</div></div></div></div></div></div></blockquote></div><br class=""></body></html>