[Mlir-commits] [mlir] [BugFix] : Fix padding calculation for tosa.transpose_conv2d decomposition. (PR #68167)

Sayan Saha llvmlistbot at llvm.org
Wed Oct 18 07:34:05 PDT 2023


sahas3 wrote:

 I was out on vacation last week, hence the delayed response. Thanks @GeorgeARM  and @eric-k256 for the feedback. I do understand now that the `output_padding` for `tosa.transpose_conv2d` is negated when compared to `padding` attribute of `tosa.conv2d`. However, I am still puzzled by the size mis-match of the output of the `tosa.conv2d` node that is produced by the decomposition transform.  

`%2 = tosa.conv2d %arg0, %1, %cst {dilation = array<i64: 1, 1>, pad = array<i64: 3, 3, 3, 3>, stride = array<i64: 1, 1>} : (tensor<1x13x10x3xf32>, tensor<2x3x3x3xf32>, tensor<2xf32>) -> tensor<1x13x10x2xf32>` doesn't seem valid to me because as per the normal calculation of computing the output size of  a convolution node 

```
(((W - K + 2P)/S) + 1)
        Here W = Input size
        K = Filter size
        S = Stride
        P = Padding 
```

the size becomes `(1, 17, 14, 2)`. This can be verified by running the `tosa-infer-shapes` pass too.

Background on this pull request is that I observed a numerical mismatch for the https://github.com/sahas3/DLModels/blob/main/conv2dTransposeSamePadding.tflite model between what IREE produces compared to TFLite. Making the padding calculation change as in this patch resolved the numeric difference issue with IREE. So that's another source of puzzle for me.

https://github.com/llvm/llvm-project/pull/68167


More information about the Mlir-commits mailing list