<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 1:46 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Apr 6, 2016 at 1:33 PM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@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 12:18 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi David,<div><br></div><div>We've been considering changing the naming scheme for promoted local functions in ThinLTO. Currently we just prepend the file name, but that isn't really sound for a number of reasons (e.g. you can have the same file name in different directories). The alternative we've been thinking about is to use the hash of all external names in the module, as that is guaranteed to be unique within a linkage unit (otherwise the linker would complain).</div><div><br></div><div>We currently (intentionally, I believe) use the same naming scheme for promoting local functions as we do for PGO, </div></div></blockquote><div><br></div></span><div>No, we don't use this naming scheme for ThinLTO promotion. It is only used for computation of the MD5 hash used in the function index (so that when we want to import a function referenced by indirect call profile info which uses this MD5 name we can find its summary). </div><div><br></div><div>The promotion name is based off a unique module identifier assigned at Thin-link time (when the combined index is generated and all bitcode files are seen).</div></div></div></div></blockquote><div><br></div></span><div>I see. I suppose that if we did form promotion names using external name hashes, we could soundly compile parts of the object file to native code at compile time, if we could somehow determine ahead of time that such compilation would be safe. I'm working on a proposal along those lines that I hope to share soon.</div></div></div></div></blockquote><div><br></div><div>This sounds reasonable to me.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>Peter</div></font></span></div>
</div></div>
</blockquote></div><br></div></div>