<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 2:08 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Teresa Johnson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
> On Wed, Apr 6, 2016 at 12:18 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
> wrote:<br>
><br>
>> Hi David,<br>
>><br>
>> We've been considering changing the naming scheme for promoted local<br>
>> functions in ThinLTO. Currently we just prepend the file name, but that<br>
>> isn't really sound for a number of reasons (e.g. you can have the same file<br>
>> name in different directories). The alternative we've been thinking about<br>
>> is to use the hash of all external names in the module, as that is<br>
>> guaranteed to be unique within a linkage unit (otherwise the linker would<br>
>> complain).<br>
>><br>
>> We currently (intentionally, I believe) use the same naming scheme for<br>
>> promoting local functions as we do for PGO,<br>
>><br>
><br>
> No, we don't use this naming scheme for ThinLTO promotion. It is only used<br>
> for computation of the MD5 hash used in the function index (so that when we<br>
> want to import a function referenced by indirect call profile info which<br>
> uses this MD5 name we can find its summary).<br>
<br>
</span>Oh good, I was worried for a second. The PGO renaming approach isn't<br>
very robust at all and will hopefully be replaced with something less<br>
fragile eventually.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Right -- the only reason we still keep the current naming scheme in PGO is due to backward compatibility concerns. We have also recently introduced a mechanism in PGO that allows us to make the change without breaking the compatibility.</div><div><br></div><div>Ideally we should have a shared API to create unique global identifier for static functions.</div><div><br></div><div>David</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> The promotion name is based off a unique module identifier assigned at<br>
> Thin-link time (when the combined index is generated and all bitcode files<br>
> are seen).<br>
><br>
> Thanks,<br>
> Teresa<br>
><br>
> so we might need to change both. Do you see any back compat concerns with<br>
>> changing the naming scheme? I guess there are various things we can do to<br>
>> try to ensure back compat, but I wanted to get an idea of what the<br>
>> requirements are.<br>
>><br>
>> Thanks,<br>
>> --<br>
>> --<br>
>> Peter<br>
>><br>
</div></div></blockquote></div><br></div></div>