[llvm] [AMDGPU][SplitModule] Handle !callees metadata (PR #108802)

[Pierre van Houtryve via llvm-commits]

================
@@ -476,12 +486,36 @@ void SplitGraph::Node::visitAllDependencies(
   }
 }
 
+/// Checks if \p I has MD_callees and if it does, parse it and put the function
+/// in \p Callees.
+///
+/// \returns true if there was metadata and it was parsed correctly. false if
+/// there was no MD or if it contained unknown entries.
+static bool handleCalleesMD(const Instruction &I,
+                            SmallVector<Function *> &Callees) {
+  auto *MD = I.getMetadata(LLVMContext::MD_callees);
+  if (!MD)
+    return false;
+
+  for (const auto &Op : MD->operands()) {
+    Function *Callee = mdconst::extract_or_null<Function>(Op);
+    if (!Callee)
+      return false;
+    Callees.push_back(Callee);
+  }
+
+  return true;
+}
+
 void SplitGraph::buildGraph(CallGraph &CG) {
   SplitModuleTimer SMT("buildGraph", "graph construction");
   LLVM_DEBUG(
       dbgs()
       << "[build graph] constructing graph representation of the input\n");
 
+  // FIXME(?): Is the callgraph really worth using if we have to iterate the
+  // function again whenever it fails to give us enough information?
----------------
Pierre-vh wrote:

> This really depends if the kernel calls an external function. Does this happen often in real-world kernels? I'd say no, but I'm not sure.

I really don't think so, but calling an external function declaration would never be a problem (we don't even model those relationships). The declarations are copied in all modules anyway

> I assume that building the callgraph is faster than scanning all the instructions, since the callgraph would only scan the uses of the functions and not all the instructions.

You're giving the callgraph a bit too much credit :)

It iterates all instructions in all functions, does a `dyn_cast` to `CallBase` and handles the result. It's not super fancy, the main advantage of the CG is to avoid duplicating that logic between passes (and I think it can survive as an analysis).

See `CallGraph::populateCallGraphNode`

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