llvm dev - Apr 2016 - ThinLTO naming scheme for promoted local functions

Hi David,

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).

We currently (intentionally, I believe) use the same naming scheme for
promoting local functions as we do for PGO, so we might need to change
both. Do you see any back compat concerns with changing the naming scheme?
I guess there are various things we can do to try to ensure back compat,
but I wanted to get an idea of what the requirements are.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160406/e61c6dbd/attachment.html>

On Wed, Apr 6, 2016 at 12:18 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> Hi David,
>
> 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).
>
> We currently (intentionally, I believe) use the same naming scheme for
> promoting local functions as we do for PGO,
>
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).

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).

Thanks,
Teresa

so we might need to change both. Do you see any back compat concerns
with
> changing the naming scheme? I guess there are various things we can do to
> try to ensure back compat, but I wanted to get an idea of what the
> requirements are.
>
> Thanks,
> --
> --
> Peter
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160406/7e0902fb/attachment.html>

On Wed, Apr 6, 2016 at 1:33 PM, Teresa Johnson <tejohnson at google.com>
wrote:
>
>
> On Wed, Apr 6, 2016 at 12:18 PM, Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>
>> Hi David,
>>
>> 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).
>>
>> We currently (intentionally, I believe) use the same naming scheme for
>> promoting local functions as we do for PGO,
>>
>
> 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).
>
> 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).
>
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.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160406/5516b42d/attachment.html>

Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> On Wed, Apr 6, 2016 at 12:18 PM, Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>
>> Hi David,
>>
>> 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).
>>
>> We currently (intentionally, I believe) use the same naming scheme for
>> promoting local functions as we do for PGO,
>>
>
> 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).
Oh good, I was worried for a second. The PGO renaming approach isn't
very robust at all and will hopefully be replaced with something less
fragile eventually.
> 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).
>
> Thanks,
> Teresa
>
> so we might need to change both. Do you see any back compat concerns with
>> changing the naming scheme? I guess there are various things we can do
to
>> try to ensure back compat, but I wanted to get an idea of what the
>> requirements are.
>>
>> Thanks,
>> --
>> --
>> Peter
>>