[Mlir-commits] [mlir] [mlir][linalg] Vectorize directly to a named contraction (PR #147296)
Andrzej Warzyński
llvmlistbot at llvm.org
Thu Jul 10 03:04:59 PDT 2025
banach-space wrote:
> However, this still leaves `linalg.contract` that can express the same computation but has no defaults.
Does it not? To me, if the maps are not uniquely defined, that would be a "bug" (as in, if there's ambiguity, it should be removed). However, taking this example:
```mlir
func.func @example%A : memref<?x?x?xf32>, %B: memref<?x?xf32>, %C: memref<?x?x?xf32>) {
linalg.contract
indexing_maps = [affine_map<(batch, m, n, k) -> (batch, k, m)>,
affine_map<(batch, m, n, k) -> (k, n)>,
affine_map<(batch, m, n, k) -> (batch, m, n)>]
ins(%A, %B: memref<?x?x?xf32>, memref<?x?xf32>)
outs(%C: memref<?x?x?xf32>)
return
}
```
"generalisation" does yield unique maps (`mlir-opt %s -split-input-file -linalg-generalize-named-ops`):
```mlir
#map = affine_map<(d0, d1, d2, d3) -> (d0, d3, d1)>
#map1 = affine_map<(d0, d1, d2, d3) -> (d3, d2)>
#map2 = affine_map<(d0, d1, d2, d3) -> (d0, d1, d2)>
module {
func.func @generalize_matmul_buffer(%arg0: memref<?x?x?xf32>, %arg1: memref<?x?xf32>, %arg2: memref<?x?x?xf32>) {
linalg.generic {indexing_maps = [#map, #map1, #map2], iterator_types = ["parallel", "parallel", "parallel", "reduction"]} ins(%arg0, %arg1 : memref<?x?x?xf32>, memref<?x?xf32>) outs(%arg2 : memref<?x?x?xf32>) {
^bb0(%in: f32, %in_0: f32, %out: f32):
%0 = arith.mulf %in, %in_0 : f32
%1 = arith.addf %out, %0 : f32
linalg.yield %1 : f32
}
return
}
}
```
What am I missing here? 🤔
https://github.com/llvm/llvm-project/pull/147296
More information about the Mlir-commits
mailing list