[llvm-dev] ThinLTO naming scheme for promoted local functions

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 6 15:20:03 PDT 2016


On Wed, Apr 6, 2016 at 1:46 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

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

This sounds reasonable to me.

David


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


More information about the llvm-dev mailing list