From 8c1bc986b598fd352262c53e6e36307d02036d3c Mon Sep 17 00:00:00 2001 From: Teresa Johnson Date: Mon, 29 Aug 2016 22:46:56 +0000 Subject: [ThinLTO] Indirect call promotion fixes for promoted local functions Summary: Fix a couple issues limiting the application of indirect call promotion in ThinLTO mode: - Invoke indirect call promotion before globalopt, since it may eliminate imported functions which appear unreferenced. - Invoke indirect call promotion with InLTO=true so that the PGOFuncName metadata is used to get the name for locals which would have been renamed during promotion. Reviewers: davidxl, mehdi_amini Subscribers: Prazek, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D24004 llvm-svn: 280024 --- llvm/lib/ProfileData/InstrProf.cpp | 3 +++ 1 file changed, 3 insertions(+) (limited to 'llvm/lib/ProfileData') diff --git a/llvm/lib/ProfileData/InstrProf.cpp b/llvm/lib/ProfileData/InstrProf.cpp index a0400721166..dac91950183 100644 --- a/llvm/lib/ProfileData/InstrProf.cpp +++ b/llvm/lib/ProfileData/InstrProf.cpp @@ -136,6 +136,9 @@ std::string getPGOFuncName(StringRef RawFuncName, // (when \c InLTO is true): LTO's internalization privatizes many global linkage // symbols. This happens after value profile annotation, but those internal // linkage functions should not have a source prefix. +// Additionally, for ThinLTO mode, exported internal functions are promoted +// and renamed. We need to ensure that the original internal PGO name is +// used when computing the GUID that is compared against the profiled GUIDs. // To differentiate compiler generated internal symbols from original ones, // PGOFuncName meta data are created and attached to the original internal // symbols in the value profile annotation step -- cgit v1.2.3