[PATCH] D78996: [MLIR][LINALG] Convert Linalg to Linalg

Ehsan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 30 09:02:42 PDT 2020


dfki-ehna marked 13 inline comments as done.
dfki-ehna added inline comments.


================
Comment at: mlir/lib/Dialect/Linalg/Transforms/TensorsToBuffers.cpp:122
+    // Mark return operations illegal as long as they return values.
+    target.addDynamicallyLegalOp<mlir::ReturnOp>(
+        [](mlir::ReturnOp returnOp) { return returnOp.getNumOperands() == 0; });
----------------
ftynse wrote:
> This looks like it would make impossible to have simple helper functions that have no Linalg in them.
> 
> ```
> func @square(%arg0: f32) {
>   %0 = mulf %arg0, %arg0 : f32
>   return %0 : f32
> }
> 
> func @foo(...) {
>   linalg.generic (...buffers...) {
>     %0 = call @square(...) : (f32) -> f32
>     linalg.yield %0 : f32
>   }
> }
> ```
Thanks for mentioning this. We addressed this issue with a quick fix to cover more test cases in this PR. However, the combination of FunctionAndBlockSignatureConverter and NonVoidToVoidReturnOpConverter of BufferAssignment would still fail in cases like the following:
```
func @function(%arg0: f32, %arg1: tensor<4xf32>) -> (f32, f32) {
  %0 = mulf %arg0, %arg0 : f32
  return %0, %0 : f32, f32
}
```
FunctionAndBlockSignatureConverter converts the function to:
```
func @function(%arg0: f32, %arg1: memref<4xf32>, f32, f32) {
  %0 = mulf %arg0, %arg0 : f32
  return %0, %0 : f32, f32
}
```
but the return operation remains unchanged and leaves the IR in a broken state.
These converters must be fixed more fundamentally and we are going to do so in the next PR.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78996/new/

https://reviews.llvm.org/D78996





More information about the llvm-commits mailing list