[llvm] r264678 - [PGO] More comments how function pointers for indirect calls are mapped

[Adam Nemet via llvm-commits]

Author: anemet
Date: Mon Mar 28 17:15:15 2016
New Revision: 264678

URL: http://llvm.org/viewvc/llvm-project?rev=264678&view=rev
Log:
[PGO] More comments how function pointers for indirect calls are mapped
to function names

Summary:
Hopefully this will make it easier for the next person to figure all
this out...

Reviewers: bogner, davidxl

Subscribers: davidxl, cfe-commits

Differential Revision: http://reviews.llvm.org/D18489

Modified:
    llvm/trunk/include/llvm/ProfileData/InstrProfData.inc

Modified: llvm/trunk/include/llvm/ProfileData/InstrProfData.inc
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ProfileData/InstrProfData.inc?rev=264678&r1=264677&r2=264678&view=diff
==============================================================================
--- llvm/trunk/include/llvm/ProfileData/InstrProfData.inc (original)
+++ llvm/trunk/include/llvm/ProfileData/InstrProfData.inc Mon Mar 28 17:15:15 2016
@@ -133,6 +133,15 @@ VALUE_PROF_FUNC_PARAM(uint32_t, CounterI
 #else
 #define INSTR_PROF_DATA_DEFINED
 #endif
+/* For indirect function call value profiling, the addresses of the target
+ * functions are profiled by the instrumented code. The target addresses are
+ * written in the raw profile data and converted to target function name's MD5
+ * hash by the profile reader during deserialization.  Typically, this happens
+ * when the the raw profile data is read during profile merging.
+ *
+ * For this remapping the ProfData is used.  ProfData contains both the function
+ * name hash and the function address.
+ */
 VALUE_PROF_KIND(IPVK_IndirectCallTarget, 0)
 /* These two kinds must be the last to be
  * declared. This is to make sure the string