[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