[Mlir-commits] [mlir] [MLIR][Linalg] Introduce linalg.contract (PR #123618)

Rolf Morel llvmlistbot at llvm.org
Tue Jan 28 04:03:38 PST 2025


================
@@ -529,6 +529,103 @@ func.func @invalid_indexing_maps_placement_matmul(%lhs: tensor<4x1xf32>, %rhs: t
 
 // -----
 
+func.func @invalid_indexing_maps_placement_contraction(
+    %lhs: tensor<4x1xf32>, %rhs: tensor<1x64xf32>, %init: tensor<4x64xf32>) {
+  // expected-error @+2 {{custom op 'linalg.contract' expected 'indexing_maps' attribute}}
----------------
rolfmorel wrote:

On the one hand, yes we could try to be more informative in such situations. On the other, the user is already pointed out that the parser `expected 'indexing_maps' attribute` at the location of the `ins` keyword - see below:
```
mlir/test/Dialect/Linalg/invalid.mlir:530 offset :7:7: error: unexpected error: custom op 'linalg.contract' expected 'indexing_maps' attribute                                                                                               
      ins(%lhs, %rhs : tensor<4x1xf32>, tensor<1x64xf32>)
      ^
```
Given the above hint is available (and there's an example in the docs), I am disinclined to complicate the parsers to produce more helpful messages in case positional things get inserted in the wrong place (e.g. this would mean each "element", e.g. `indexing_maps` and `ins(..)` and `outs(..)` needs to be parsed optionally and all error reporting needs to gathered at the end of the parsing function even though we noticed the error right at the start). If there's consensus for doing things this way, I am happy to consider it though.

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


More information about the Mlir-commits mailing list