| Issue |
134907
|
| Summary |
[mlir][tosa] : pool op verification changes are possibly too restrictive?
|
| Labels |
mlir
|
| Assignees |
|
| Reporter |
sahas3
|
The following `tfl` IR
```
func.func @pool(%arg0 : tensor<1x60x59x5xf32>) -> tensor<1x30x29x5xf32> {
%0 = "tfl.max_pool_2d"(%arg0) <{filter_height = 2 : i32, filter_width = 2 : i32, fused_activation_function = "NONE", padding = "VALID", stride_h = 2 : i32, stride_w = 2 : i32}> : (tensor<1x60x59x5xf32>) -> tensor<1x30x29x5xf32>
return %0 : tensor<1x30x29x5xf32>
}
```
produces the `tosa` IR using the `tf-opt` executable available in `tensorflow` repository:
```
func.func @pool(%arg0: tensor<1x60x59x5xf32>) -> tensor<1x30x29x5xf32> {
%0 = tosa.max_pool2d %arg0 {kernel = array<i64: 2, 2>, pad = array<i64: 0, 0, 0, 0>, stride = array<i64: 2, 2>} : (tensor<1x60x59x5xf32>) -> tensor<1x30x29x5xf32>
return %0 : tensor<1x30x29x5xf32>
}
```
The above IR used to lower to `linalg` fine:
```
func.func @pool(%arg0: tensor<1x60x59x5xf32>) -> tensor<1x30x29x5xf32> {
%cst = arith.constant -3.40282347E+38 : f32
%0 = tensor.empty() : tensor<1x30x29x5xf32>
%1 = linalg.fill ins(%cst : f32) outs(%0 : tensor<1x30x29x5xf32>) -> tensor<1x30x29x5xf32>
%2 = tensor.empty() : tensor<2x2xf32>
%3 = linalg.pooling_nhwc_max {dilations = dense<1> : vector<2xi64>, strides = dense<2> : vector<2xi64>} ins(%arg0, %2 : tensor<1x60x59x5xf32>, tensor<2x2xf32>) outs(%1 : tensor<1x30x29x5xf32>) -> tensor<1x30x29x5xf32>
return %3 : tensor<1x30x29x5xf32>
}
```
But now due to https://github.com/llvm/llvm-project/pull/130052 the `tosa` IR is failing with 'tosa.max_pool2d' op expected input_width + pad_left + pad_right - kernel_x to be wholly divisible by stride_x, got (59 + 0 + 0 - 2) / 2
The padding values for `VALID` padding is [determined](https://www.tensorflow.org/api_docs/python/tf/keras/layers/MaxPool2D) as
> The resulting output when using the "valid" padding option has a spatial shape (number of rows or columns) of: output_shape = math.floor((input_shape - pool_size) / strides) + 1
It seems to me this check is too restrictive and doesn't take into account the above equation properly as `input + pad_left + pad_right - kernel` can be not a multiple of `stride`.
Should this check be reverted or the lowering from `tfl` to `tosa` should be adjusted somehow to honor this check?
Any thoughts @lhutton1, @GeorgeARM, @sjarus?
Thanks!
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
