[llvm] [AsmPrint] Correctly factor function entry count when dumping MBB frequencies (PR #67826)

[Aiden Grossman via llvm-commits]

================
@@ -1929,18 +1929,35 @@ void AsmPrinter::emitFunctionBody() {
 
   // Output MBB ids, function names, and frequencies if the flag to dump
   // MBB profile information has been set
-  if (MBBProfileDumpFileOutput) {
+  if (MBBProfileDumpFileOutput && !MF->empty()) {
     if (!MF->hasBBLabels())
       MF->getContext().reportError(
           SMLoc(),
           "Unable to find BB labels for MBB profile dump. -mbb-profile-dump "
           "must be called with -basic-block-sections=labels");
     MachineBlockFrequencyInfo &MBFI =
         getAnalysis<LazyMachineBlockFrequencyInfoPass>().getBFI();
+    // The entry count and the entry basic block frequency aren't the same. We
+    // want to capture "absolute" frequencies, i.e. the frequency with which a
+    // MBB is executed when the program is executed - from there, we can derive
+    // Function-relative frequencies (divide by the value for the first MBB),
+    // and we also have the information about frequency with which functions
+    // were called. This helps, for example, in a type of integration tests
+    // where we want to cross-validate the compiler's profile with a real
+    // profile.
+    // Using double precision because uint64 values used to encode mbb
+    // "frequencies" may be quite large.
+    const double EntryCount =
+        static_cast<double>(MF->getFunction().getEntryCount()->getCount());
+    const double EntryFrequency =
+        static_cast<double>(MBFI.getBlockFreq(&*MF->begin()).getFrequency());
----------------
boomanaiden154 wrote:

That would produce the desired values and not break the abstraction, but it will change the precision of the result, returning a `float` instead of a `double`. Not sure how much that matters in practice, but the intention here seems to be to use a `double`.

Also, if we want to preserve this abstraction, maybe we mark `getFrequency()` as private and use friend classes where necessary to make the API easier to use, depending upon how the implementation here ends up going?

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