[compiler-rt] [llvm] [InstrPGO][TypeProf]Annotate vtable types when they are present in the profile (PR #99402)

Mingming Liu via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 18 11:58:19 PDT 2024


================
@@ -1755,8 +1757,18 @@ void PGOUseFunc::annotateValueSites() {
 void PGOUseFunc::annotateValueSites(uint32_t Kind) {
   assert(Kind <= IPVK_Last);
   unsigned ValueSiteIndex = 0;
-  auto &ValueSites = FuncInfo.ValueSites[Kind];
   unsigned NumValueSites = ProfileRecord.getNumValueSites(Kind);
+  // FuncPGOInstrumentation ctor finds value sites for each kind. It runs on the
+  // common path of pgo-instr-gen and pgo-instr-use, and vtable kind path
+  // is gated by `-enable-vtable-value-profiling`. If vtable profiles are
+  // present, not explicitly discarded and vtable sites remain empty, try to
+  // find the sites again.
----------------
minglotus-6 wrote:

This runs on the common path of `pgo-instr-gen` and `pgo-instr-run`. There isn't a reliably way to tell if iFDO profile are generated with `--enable-vtable-value-profiling` or not [1], and it's preferred to have an option to disable `VPC.get(IPVK_VTableTarget)` (which iterates instructions and collect instrumentation sites via InstVisitor)

As discussed, I simplified this code by 
* Enable value-profile-collector (VPC) instruction iteration for optimized build.
* Allow skipping `VPC.get(IPVK_VTableTarget)`

[1] if a program doesn't use vtable but its instrumented profiles are generated with `--enable-vtable-value-profiling=true`, iterating function profile record won't tell this with the current profile format.

https://github.com/llvm/llvm-project/pull/99402


More information about the llvm-commits mailing list