[Mlir-commits] [mlir] [mlir] support non-interprocedural dataflow analyses (PR #75583)

[Oleksandr Alex Zinenko]

================
@@ -54,12 +54,22 @@ LogicalResult AbstractDenseForwardDataFlowAnalysis::visit(ProgramPoint point) {
 }
 
 void AbstractDenseForwardDataFlowAnalysis::visitCallOperation(
-    CallOpInterface call, AbstractDenseLattice *after) {
+    CallOpInterface call, const AbstractDenseLattice &before,
+    AbstractDenseLattice *after) {
+  // Allow for customizing the behavior of calls to external symbols, including
+  // when the analysis is explicitly marked as non-interprocedural.
+  auto callable =
+      dyn_cast_if_present<CallableOpInterface>(call.resolveCallable());
+  if (!getSolverConfig().isInterprocedural() ||
+      (callable && !callable.getCallableRegion())) {
----------------
ftynse wrote:

For indirect calls, `callable` will be null so we won't enter this branch. The control flow will proceed and, in the generic case, will enter branch with "not all predecessors known" condition because we can't reason about the callee of indirect calls. That will set everything to fixpoint and return, so it is conservatively correct. I haven't double-checked, but there may be a rare but happier situation where the set of possible callees is actually known (constant propagation or some custom logic), at which point we will be able to proceed interprocedurally. 

We could add a customization hook for this situation, but I believe it should be different from "external callee" as (1) the callee is not necessarily external and (2) the implementer of the hook could benefit from knowing we are in the "unknown callee" situation. I'd suggest doing this as a separate change to we see the effects it has on various tests

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