[llvm] [llvm-profgen] Improve sample profile density (PR #92144)

[Lei Wang via llvm-commits]

================
@@ -768,9 +748,89 @@ void ProfileGenerator::populateBoundarySamplesForAllFunctions(
   }
 }
 
+// Note taht ideally the size should be the number of function's instruction.
+// However, for probe-based profile, we don't have the accurate instruction
+// count for each probe, Instead, the probe sample is the samples count for the
+// block, which is equivelant to total_instruction_samples/num_instruction in
+// one block. Hence, we use the number of probe as a proxy for the function's
+// size.
+void ProfileGeneratorBase::calculateBodySamplesAndSize(
+    const FunctionSamples &FSamples, uint64_t &TotalBodySamples,
----------------
wlei-llvm wrote:

> Even though `--update-total-samples` is off, how big of a difference do we expect between total samples and the way you compute it? I actually don't remember what is the source of discrepency, and still don't understand why we have regression. If they are close enough, it shouldn't matter for computing density?

It could be 2X~10X bigger, the multiplier is equal to how many physical instruction one source instruction(debug-line) emits, usually one source code line can generate many physical instructions, it could be big. 

There is an example in our test case: https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-profgen/inline-noprobe.test#L17-L45

See the `CHECK: main:2609:0` vs `CHECK-UPDATE-TOTAL-SAMPLE: main:292:0`, it could be ~10X. 

it's indeed hard to understand why it can cause regression, it's just the observation from data. 

 

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