[Mlir-commits] [mlir] [mlir][spirv] Add a generic `convert-to-spirv` pass (PR #95942)

[llvmlistbot at llvm.org]

================
@@ -31,6 +31,18 @@ def ConvertToLLVMPass : Pass<"convert-to-llvm"> {
   ];
 }
 
+//===----------------------------------------------------------------------===//
+// ToSPIRV
+//===----------------------------------------------------------------------===//
+
+def ConvertToSPIRVPass : Pass<"convert-to-spirv"> {
+  let summary = "Convert to SPIR-V";
+  let description = [{
+    This is a generic pass to convert to SPIR-V.
----------------
MaheshRavishankar wrote:

> > I think this pass is used by the runner. Can we have a test pass that is used by the vulkan runner?
> 
> The runner is supposed to be removed as far as I know (it seems that's another topic that needs a new push by the way...).
> 
> So tTat has me even more concerned now! This is a major misalignment to add new stuff to this runner when we agreed before that it should be removed...

Well, the runner is a tangent. W.R.T this pass itself, I think the end-state is what you are looking for. So it might be too monolithic to start with, but I think it is better to have it in tree an iterate on. In terms of moving it to a test pass, that is an option too.

W.R.T the runner, my only concern is that we have pretty woeful testing in MLIR, and without having some limited e2e runners that provide some basic gaurantees, Already I feel this testing hole is being filled by downstream projects like IREE (for example, almost every dialect conversion change that is being landed in MLIR is failing downstream, and then its a PROCESS to triage and provided repro and get through the part of is this a downstream issue or actual bug. I appreciate all the changes being made, but this is making it clear that there is just not enough testing in tree to catch these issues before hand. So we can drop the runner, but it will just make the situation worse).  So I think dropping the runner, or moving it to post-submit and then moving this pass to a test pass is an option, but requires someone to "own" all of this. I would rather let the stake-holders here (which for now is Lei and Jakub) decide how they want to manage the conversion to spir-v passes since they are also the users of this stuff downstream. They seem to agree that the end state is to be closer to LLVM lowering, but might get there in a few steps.

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