[Mlir-commits] [mlir] [mlir] Remove the mlir-spirv-cpu-runner (move to mlir-cpu-runner) (PR #114563)

[Renato Golin]

================
@@ -17,10 +17,65 @@
 #include "mlir/ExecutionEngine/OptUtils.h"
 #include "mlir/IR/Dialect.h"
 #include "mlir/Target/LLVMIR/Dialect/All.h"
+#include "mlir/Target/LLVMIR/Dialect/LLVMIR/LLVMToLLVMIRTranslation.h"
+#include "mlir/Target/LLVMIR/Export.h"
 
+#include "llvm/IR/LLVMContext.h"
+#include "llvm/IR/Module.h"
+#include "llvm/Linker/Linker.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/TargetSelect.h"
 
+using namespace mlir;
+
+llvm::cl::opt<bool> LinkNestedModules(
+    "link-nested-modules",
+    llvm::cl::desc("Link two nested MLIR modules into a single LLVM IR module. "
+                   "Useful if both the host and device code can be run on the "
+                   "same CPU, as in mlir-spirv-cpu-runner tests."));
----------------
rengolin wrote:

We have a similar tug-of-war between our `opt` and `runner` apps (based on the same principles). 

We had to solve the problem of ingress: which IR stage (dialects, passes) to accept. `opt` takes in anything, but `runner` is more complicated, because it needs to lower to LLVM/SPIRV to actually execute, and if the IR is in `linalg`, then it's not going to work. The solution for this is to pass it through `opt` until it's in the right shape, then pipe to `runner`, but defining what the "right shape" is, is the point here.

Let's assume `runner` can only handle LLVM and SPIRV, then the main problem with merging the runners is to document which of these two can be used for which "back-end", and how to drive the back-end (tools, LLVM codegen, dispatch, JIT) with these dialects.

Regardless, I think this is super important and needs to happen. The main difference in code is which MLIR/LLVM functions are called, and some configuration issues, which we can probable common up for all these cases.

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