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

Amir Ayupov via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Wed Jul 24 14:29:21 PDT 2024


================
@@ -208,11 +212,33 @@ class StaleMatcher {
     }
   }
 
-  /// Find the most similar block for a given hash.
-  const FlowBlock *matchBlock(BlendedBlockHash BlendedHash,
-                              uint64_t CallHash) const {
+  /// Creates a mapping from a pseudo probe index to pseudo probe.
+  void mapIndexToProbe(uint64_t Index, const MCDecodedPseudoProbe *Probe) {
+    IndexToBBPseudoProbes[Index].push_back(Probe);
+  }
+
+  /// Creates a mapping from a pseudo probe to a flow block.
+  void mapProbeToBB(const MCDecodedPseudoProbe *Probe, FlowBlock *Block) {
+    BBPseudoProbeToBlock[Probe] = Block;
+  }
+
+  /// Find the most similar flow block for a profile block given its hashes and
+  /// pseudo probe information.
+  const FlowBlock *
+  matchBlock(BlendedBlockHash BlendedHash, uint64_t CallHash,
+             const std::vector<yaml::bolt::PseudoProbeInfo> &PseudoProbes) {
     const FlowBlock *BestBlock = matchWithOpcodes(BlendedHash);
-    return BestBlock ? BestBlock : matchWithCalls(BlendedHash, CallHash);
+    if (BestBlock) {
+      ++MatchedWithOpcodes;
+      return BestBlock;
+    }
+    BestBlock = matchWithCalls(BlendedHash, CallHash);
+    if (BestBlock)
+      return BestBlock;
+    BestBlock = matchWithPseudoProbes(BlendedHash, PseudoProbes);
----------------
aaupov wrote:

> I'm a bit unsure about the strategy here. This is assuming matching of each individual block/node is an isolated problem. But the reality is, it's not, instead we're matching two sets of nodes (or rather two graphs) holistically.

Agree but we're trying to lay the foundation with only block matching belonging to the current function. Your comment makes me rethink probe filtering based on GUID - cc @shawbyoung.

> I.e. if we function's CFG hash matches that from probe desc, we should be able to have high confidence exact mapping for all blocks based on probe, and shouldn't need to treat probe based matching as a fallback?

Exact hash provides a stronger signal than probes and is available for all binary basic blocks, so it makes sense to put it to the top. I'm on the fence about the relative strengths of call hash and probes: call hash is supposedly cheaper to construct but might not be available for all blocks. Stats from both should help us make the right call.

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


More information about the llvm-branch-commits mailing list