[llvm-branch-commits] [llvm] [BOLT] Match blocks with pseudo probes (PR #99891)

[Lei Wang via llvm-branch-commits]

================
@@ -478,10 +675,34 @@ matchWeightsByHashes(BinaryContext &BC,
     Blocks.push_back(&Func.Blocks[I + 1]);
     BlendedBlockHash BlendedHash(BB->getHash());
     BlendedHashes.push_back(BlendedHash);
+    // Collects pseudo probes attached to the BB for use in the StaleMatcher.
+    if (opts::ProfileUsePseudoProbes &&
+        opts::StaleMatchingWithBlockPseudoProbes && PseudoProbeDecoder) {
+      const AddressProbesMap &ProbeMap =
+          PseudoProbeDecoder->getAddress2ProbesMap();
+      const uint64_t FuncAddr = BF.getAddress();
+      const std::pair<uint64_t, uint64_t> &BlockRange =
+          BB->getInputAddressRange();
+      const auto &BlockProbes =
+          llvm::make_range(ProbeMap.lower_bound(FuncAddr + BlockRange.first),
+                           ProbeMap.lower_bound(FuncAddr + BlockRange.second));
+      for (const auto &[_, Probes] : BlockProbes) {
+        for (const MCDecodedPseudoProbe &Probe : Probes) {
+          if (Probe.getType() != static_cast<uint8_t>(PseudoProbeType::Block))
+            continue;
+          if (Probe.getInlineTreeNode()->hasInlineSite())
+            Matcher.mapGUIDAndIndexToProbe(Probe.getGuid(), Probe.getIndex(),
+                                           &Probe);
+          else
+            Matcher.mapIndexToProbe(Probe.getIndex(), &Probe);
----------------
wlei-llvm wrote:

It's surprised to me that there are 75% of top level probes, which means compiler inlining introduces only 25% probes/blocks, but in fact, PGO inlining is aggressive which can inline 12X more size(https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/IPO/SampleProfile.cpp#L207) than the original function(the top-level probes).

Even to use two-level look up, that's still constant time complexity, it should not be an issue? I saw large duplicated codes in `matchWithInlinedBlockPseudoProbes` and `matchWithNonInlinedBlockPseudoProbes`, using one container and unify them can be good for the future maintenance.   And also wondering if the map is for other use or just look up? If no other use, how about use combine hash(std::pair<...>(GUID, Index) as a key, then we don't need to use the 2-D DenseMap. 



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