Current profile generation caculcates callsite body samples and call target samples separately. The former is done based on LBR range samples while the latter is done based on branch samples. Note that there's a subtle difference. LBR ranges is formed from two consecutive branch samples. Therefore the last entry in a LBR record will not be counted towards body samples while there's still a chance for it to be counted towards call targets if it is a function call. I'm making sense of the call body samples by updating it to the aggregation of call targets.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/ProfileData/SampleProf.h | ||
---|---|---|
749 |
Based on this theory, is it actually possible for I.second.getSamples() to be larger than TargetSamples? | |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
92 | I'm not sure if we need a switch here. It feels to me that we should always try to make the counts consistent. But ofc, that means more testing is needed. | |
llvm/tools/llvm-profgen/ProfileGenerator.h | ||
97 | nit: updateFunctionSamples? |
llvm/include/llvm/ProfileData/SampleProf.h | ||
---|---|---|
749 | Actually it is possible. If some call targets are external targets, they won't be counted, but the body sample count which is from the lbr ranges can include them. | |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
92 | Makes sense to make it unconditional. Regarding testing, it should have minimal impact on CS probe profile. I'll test for regular non-CS profile. | |
llvm/tools/llvm-profgen/ProfileGenerator.h | ||
97 | done. |
Updating D122609: [llvm-profgen] An option to update callsite body samples by summing up all call target samples.
Updating D122609: [llvm-profgen] Update callsite body samples by summing up all call target samples.
what triggered this change?