[llvm-branch-commits] [llvm] [BOLT] Match blocks with calls as anchors (PR #96596)

[Shaw Young via llvm-branch-commits]

================
@@ -155,5 +155,51 @@ std::string hashBlockLoose(BinaryContext &BC, const BinaryBasicBlock &BB) {
   return HashString;
 }
 
+/// An even looser hash of a basic block to use with stale profile matching,
+/// composed of the names of a block's called functions in lexicographic order.
+std::string hashBlockCalls(BinaryContext &BC, const BinaryBasicBlock &BB) {
+  // The hash is computed by creating a string of all lexicographically ordered
+  // called function names.
+  std::multiset<std::string> FunctionNames;
+  for (const MCInst &Instr : BB) {
+    // Skip non-call instructions.
+    if (!BC.MIB->isCall(Instr))
+      continue;
+    const MCSymbol *CallSymbol = BC.MIB->getTargetSymbol(Instr);
+    if (!CallSymbol)
----------------
shawbyoung wrote:

It can happen in either case - e.g. call to function pointer. In any case we don't want an assertion failure - it's not "wrong" in either case for the CallSymbol to be null. For instance, in PLTCall we're replacing calls to PLT functions with indirect calls against GOT - ignoring call instructions with null CallSymbols shouldn't impact the pass' correctness. Similarly when computing CallHashes (meant to be a looser hash than opcode hash), ignoring call instructions with null CallSymbols won't impact correctness. 

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