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

[Andrea Faulds]

================
@@ -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."));
----------------
andfau-amd wrote:

Hmm, I feel like I'm pulled in two different directions here. My goal was to get rid of the separate SPIR-V CPU runner, and the most straightforward way to accomplish that has been to move the codegen steps (SPIR-V -> LLVM MLIR and LLVM MLIR -> LLVM IR) into mlir-opt and mlir-cpu-runner respectively, and that _is_ bringing it more into alignment with the other runners. But for the Vulkan SPIR-V runner, these codegen steps necessarily happen inside the runner, or rather something like them happens inside the Vulkan driver that'll be dynamically linked in (SPIR-V -> [something proprietary] -> LLVM IR -> [native binary]). So if we want the SPIR-V CPU runner to work the same as the Vulkan SPIR-V runner, then we would probably have to move the codegen back into the runner, so that the mlir-opt output can just be SPIR-V.

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