[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:19:17 PDT 2016
On Wed, Apr 6, 2016 at 2:08 PM, Justin Bogner <mail at justinbogner.com> wrote:
> 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
> >> name in different directories). The alternative we've been thinking
> >> 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
> >> 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
> > for computation of the MD5 hash used in the function index (so that when
> > 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.
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
Ideally we should have a shared API to create unique global identifier for
> The promotion name is based off a unique module identifier assigned at
> > Thin-link time (when the combined index is generated and all bitcode
> > 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
> >> 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...
More information about the llvm-dev