[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