<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 10:52 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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:41 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></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">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>2) The function's instruction count falls above a threshold specified at compile time, so it will never be imported.</div><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></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 dir="ltr"><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. 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></blockquote><div><br></div><div><br></div></span><div>3) sounds like a good use case (though very unique to CFI. Generally, a function body will be affected by link time decisions including whole program analyses).  In this mode, do we really need to emit the bit code section at all? There does not any need for static promotions if we assume no cross module transformations will happen in this mode.</div></div></div></div></blockquote><div><br></div><div>We still need some way to generate the correct code for the CFI intrinsics, which rely on cross module information. That information would come directly from the combined summary, rather than being imported from other modules.</div><div><br></div><div>Peter</div></div>
</div></div>