[Mlir-commits] [mlir] [mlir][linalg] Fix a DCE crash with memref<0x..> and the op has uses (PR #73908)

[Kohei Yamaguchi]

================
@@ -47,6 +47,31 @@ func.func @dce_zero_memref(%arg0 : memref<0xf32>, %arg1: tensor<0xf32>) -> tenso
 
 // -----
 
+#accesses = [
+  affine_map<(i) -> (i)>,
+  affine_map<(i) -> (i)>
+]
+
+#trait = {
+  indexing_maps = #accesses,
+  iterator_types = ["parallel"]
+}
+
+func.func @no_dce_zero_memref(%arg0 : memref<0xf32>, %arg1: tensor<0xf32>) -> tensor<0xf32> {
+  // memref<0xf32> cannot be dce'ed
+  %2 = linalg.generic #trait ins(%arg0: memref<0xf32>) outs(%arg1 : tensor<0xf32>) {
----------------
sott0n wrote:

I think that it would be a good idea to verify whether the mix of memref/tensor is present in the operand of inputs in the [verifyStructuredOpInterface of LinalgOp](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Linalg/IR/LinalgInterfaces.cpp#L1006). 

However, I'm unsure whether it is correct to restrict the mix of memref/tensor in the input for the entire LinalgOp. Is it correct?

For example, in the [linalg_effects test](https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/Linalg/canonicalize.mlir#L110), there is a case where tensor/memref mixing exists in the inputs of linalg.matmul, and it is unclear whether such mixing is allowed in linalg.matmul.

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