<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 6, 2016, at 9:32 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com" class="">tejohnson@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 1:46 PM, Peter Collingbourne<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</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 dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Apr 6, 2016 at 1:33 PM, Teresa Johnson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tejohnson@google.com" target="_blank" class="">tejohnson@google.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 dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Wed, Apr 6, 2016 at 12:18 PM, Peter Collingbourne<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</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 dir="ltr" class="">Hi David,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">We currently (intentionally, I believe) use the same naming scheme for promoting local functions as we do for PGO,<span class="Apple-converted-space"> </span></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">I mentioned this verbally to Peter, but for the sake of discussion, using this proposed renaming scheme also has the advantage that the renaming does not depend on the link order. The current ThinLTO renaming depends on the order the bitcode files are seen on the link line. That makes it harder to share the same resulting native object file between links into diffferent binaries, since the ThinLTO-link-assigned module ID will depend on the link ordering. Of course, you would also need to determine that the import set is the same to reuse an existing native object file from another build, but this helps reduce the barrier.</div><div class=""><br class=""></div><div class="">Note that this is orthogonal to whether the new renaming scheme is done in the ThinLTO backends (current) or moved to the compile step (part of what Peter is proposing for early native code generation).</div></div></div></blockquote><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=""><br class=""></div><div class="">Doing this new renaming in the ThinLTO backend (rather than moving it up to the compile step) just requires recording this hash value in the combined index's module symbol table (where the module path and id are currently held).</div></div></div></blockquote><div><br class=""></div><div>It is not clear to me why you need the hash value in the combined index? Can’t you compute it from the summary? (by changing the definition from the "hash of public function names” to “hash of public function GUID”).</div><div>I was working on changing the naming to use the “module hash” itself as a suffix, but this hash (from global function name) seems as good for this purpose.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div></div></body></html>