llvm / llvm/llvm-project

linalg.map inconsistent in whether payload may use the init operand elements

Open
#196,959 4 comments 0 reactions 0 assignees View on GitHub
mlir:linalg
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

A recent change (#162742) made `linalg.map` take a payload, like `linalg.generic`, with an argument corresponding the the DPS init operand.

It is not clear whether that change is also meant to allow the payload to _use_ the init argument.

The `linalg::MapOp::verify()` method does not verify that the init argument is unused ([link](https://github.com/llvm/llvm-project/blob/dd907ed5f58b6313dccbec9ea36e291c2ab2f984/mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp#L1674)). Verified by the below IR example, which is accepted by recent `mlir-opt`.

The `linalg::MapOp::payloadUsesOperand()` method assumes that the init argument is unused ([link](https://github.com/llvm/llvm-project/blob/dd907ed5f58b6313dccbec9ea36e291c2ab2f984/mlir/include/mlir/Dialect/Linalg/IR/LinalgStructuredOps.td#L295)).

So, it seems one of these is incorrect. I do not think the documentation of `linalg.map` has changed to say that the payload may now use the init argument.

```mlir
func.func @map_init_used(%arg0: tensor<64xf32>, %arg1: tensor<64xf32>) -> tensor<64xf32> {
%mapped = linalg.map ins(%arg0 : tensor<64xf32>) outs(%arg1 : tensor<64xf32>)
(%in: f32, %init: f32) {
%0 = arith.addf %in, %init : f32
linalg.yield %0 : f32
}
return %mapped : tensor<64xf32>
}
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.