[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