[PATCH] D30754: SamplePGO ThinLTO ICP fix for local functions.

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 9 14:14:57 PST 2017


tejohnson added a comment.

Thanks for updating the description, it makes more sense now. A few wording suggestions below, and comments on the code following that.

> In SamplePGO, if the profile is collected from non-LTO binary, and used to drive ThinLTO, the indirect call promotion may fail because the function name will mismatch as ThinLTO added module ID in the local function name. There are two places of where the mismatch can happen:

As you note below it isn't really a single problem of adding a module ID. I would just change this to say that ThinLTO adjusts local function names to avoid conflicts.

> 
> 
> 1. thin-link appends SourceFileName to front of FuncName to build the GUID (GlobalValue::getGlobalIdentifier)

s/appends/prepends/. Also add the fact that unlike instrumentation FDO, SamplePGO does not use the PGOFuncName scheme and therefore the indirect call target profile data contains a hash of the OriginalName.

> 2. backend compiler promotes some local functions to global and appends .llvm.{$ModuleHash} to the end of the FuncName to derive UpdatedFunctionName

Clearer to call this PromotedFunctionName.

> This patch tries at the best effort to find the GUID from the original local function name (in profile), and use that in ICP promotion:

(and in SamplePGO matching that happens in the backend after importing/inlining)

> 1. in thin-link, it builds the map from OriginalName to GUID so that when thin-link reads in indirect call target profile (represented by OriginalName), it knows which GUID to import.
> 2. in backend compiler, if sample profile reader cannot find a profile match for UpdatedFunctionName, it will try to find if there is a match for OriginalFunctionName.
> 3. in backend compiler, we build symbol table entry for OriginalFunctionName and pointer to the same symbol of UpdatedFunctionName, so that ICP can find the correct target to promote.





================
Comment at: include/llvm/IR/ModuleSummaryIndex.h:564
+  const const_gvsummary_iterator
+  findGlobalValueSummaryListFromOriginalID(GlobalValue::GUID &ValueGUID) const {
+    const auto I = OidGuidMap.find(ValueGUID);
----------------
The fact that ValueGUID may be modified should be documented. But I have a suggestion about this down in selectCallee where it is invoked.


================
Comment at: include/llvm/ProfileData/SampleProfReader.h:288
+      return &Profiles[F.getName()];
+    if (Profiles.count(F.getName().split('.').first))
+      return &Profiles[(F.getName().split('.').first)];
----------------
Needs comment


================
Comment at: lib/ProfileData/InstrProf.cpp:302
+    if (InLTO) {
+      auto pos = PGOFuncName.find('.');
+      if (pos != std::string::npos) {
----------------
Needs comment.


================
Comment at: lib/Transforms/IPO/FunctionImport.cpp:179
+  if (CalleeSummaryList == Index.end()) {
+    CalleeSummaryList = Index.findGlobalValueSummaryListFromOriginalID(GUID);
+    if (CalleeSummaryList == Index.end())
----------------
I think it would be better to detect whether we need to update the GUID in the caller, in computeImportForFunction, and explicitly update the GUID there near the start of the loop. It will make what is going on clearer. Also, there is at least one check done based on the GUID early in that loop (to see if it is already in the dest module), that should be done on the updated GUID.


================
Comment at: test/Bitcode/thinlto-function-summary-originalnames.ll:17
 ; COMBINED-NEXT:   <COMBINED_ENTRY {{.*}} op1=4947176790635855146/>
+; COMBINED-NEXT:   <COMBINED_ENTRY {{.*}} op1=6699318081062747564/>
 ; COMBINED-NEXT:   <COMBINED_ENTRY {{.*}} op1=-6591587165810580810/>
----------------
Why do we need to emit these in the combined index? We have the mappings available via the COMBINED_ORIGINAL_NAME if we need to recreate the relationship.


================
Comment at: test/Transforms/PGOProfile/thinlto_samplepgo_icp.ll:6
+
+; Checks if static target functions are properly imported and promoted.
+; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc -o %t4.bc -print-imports 2>&1 | FileCheck %s --check-prefix=IMPORTS
----------------
Maybe, "calls to static target functions..." (I assume the promotion you are referring to is the ICP on the call, not the promotion to global of the static function?).
I assume that the GUID in the value profile metadata is from the original name - add comment to that effect?


https://reviews.llvm.org/D30754





More information about the llvm-commits mailing list