[llvm] [TRE] Adjust function entry count when using instrumented profiles (PR #143987)

[Mircea Trofin via llvm-commits]

================
@@ -735,6 +757,28 @@ bool TailRecursionEliminator::eliminateCall(CallInst *CI) {
   CI->eraseFromParent();   // Remove call.
   DTU.applyUpdates({{DominatorTree::Insert, BB, HeaderBB}});
   ++NumEliminated;
+  if (OrigEntryBBFreq) {
+    assert(F.getEntryCount().has_value());
+    // This pass is not expected to remove BBs, only add an entry BB. For that
+    // reason, and because the BB here isn't the new entry BB, the BFI lookup is
+    // expected to succeed.
+    assert(&F.getEntryBlock() != BB);
+    auto RelativeBBFreq =
+        static_cast<double>(BFI->getBlockFreq(BB).getFrequency()) /
+        static_cast<double>(OrigEntryBBFreq);
+    auto OldEntryCount = F.getEntryCount()->getCount();
+    auto ToSubtract =
+        static_cast<uint64_t>(std::round(RelativeBBFreq * OldEntryCount));
+    if (OldEntryCount <= ToSubtract) {
+      LLVM_DEBUG(
+          errs() << "[TRE] The entrycount attributable to the recursive call, "
+                 << ToSubtract
+                 << ", should be strictly lower than the original function "
+                    "entry count, "
+                 << OldEntryCount << "\n");
+    }
+    F.setEntryCount(OldEntryCount - ToSubtract, F.getEntryCount()->getType());
----------------
mtrofin wrote:

This is about broken profile information. I believe there we need a systematic approach (and we have a RFC[1] for that). In the interim, I don't think this is marking expected and testable behavior, this here is really just a weaker kind of assert (weaker, because compilation can continue. Which is in-line with how profile info has been currently treated. I don't like that - hence aforementioned RFC - but this check won't change the underlying problem either).

wdyt?

[1] https://discourse.llvm.org/t/rfc-profile-information-propagation-unittesting/73595/

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