[Mlir-commits] [mlir] [mlir] Remove the mlir-spirv-cpu-runner (move to mlir-cpu-runner) (PR #114563)
Andrea Faulds
llvmlistbot at llvm.org
Thu Nov 7 04:29:37 PST 2024
================
@@ -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:
Maybe theoretically? But the problem is that mlir-opt produces MLIR, and this linking is done at the LLVM IR level, not at the MLIR one. So we would have to move the conversion to LLVM IR into mlir-opt, then the linking, then it would have to turn that back into MLIR of some kind. I'm not sure what the benefit would be. It's a lot more straightforward to leave this in the runner.
https://github.com/llvm/llvm-project/pull/114563
More information about the Mlir-commits
mailing list