[MLIR]Inconsistent Results from `tosa.arithmetic_right_shift` Operation

[sweead]

test commit: 98e8f01

Description:

The tosa.arithmetic_right_shift operation should always yield a consistent result when applied to the same inputs. However, executing the same lowering sequence multiple times produces inconsistent results.

Steps to Reproduce:

Minimal MLIR program (test.mlir):

module {
  func.func private @printMemrefI16(tensor<*xi16>) attributes {llvm.emit_c_interface}
  func.func @main() {
    %0 = "tosa.const"() <{values = dense<53> : tensor<2xi16>}> : () -> tensor<2xi16>
    %1 = "tosa.const"() <{values = dense<10> : tensor<2xi16>}> : () -> tensor<2xi16>
    %2 = tosa.arithmetic_right_shift %1, %0 {round = true} : (tensor<2xi16>, tensor<2xi16>) -> tensor<2xi16>
    %cast = tensor.cast %2 : tensor<2xi16> to tensor<*xi16>
    call @printMemrefI16(%cast) : (tensor<*xi16>) -> ()
    return
  }
}

Command:

/home/workdir/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" | \
/home/workdir/llvm-project-latest/build/bin/mlir-opt -tosa-to-arith \
-one-shot-bufferize="bufferize-function-boundaries=1"  \
-convert-linalg-to-affine-loops \
-lower-affine \
-convert-scf-to-cf \
-convert-to-llvm | \
/home/workdir/llvm-project/build/bin/mlir-runner -e main -entry-point-result=void -shared-libs=/home/workdir/llvm-project/build/lib/libmlir_runner_utils.so

Output:

The results are inconsistent. Possible output include:

[0,  0]

[7134,  -31124]

[10,  0]

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Anonymous_reporter (sweead)

test commit: [98e8f01](https://github.com/llvm/llvm-project/commit/98e8f01d183177a4f54187c23183da50a7cf6daf)

Description:

The tosa.arithmetic_right_shift operation should always yield a consistent result when applied to the same inputs. However, executing the same lowering sequence multiple times produces inconsistent results.

Steps to Reproduce:

Minimal MLIR program (test.mlir):

module {
  func.func private @<!-- -->printMemrefI16(tensor&lt;*xi16&gt;) attributes {llvm.emit_c_interface}
  func.func @<!-- -->main() {
    %0 = "tosa.const"() &lt;{values = dense&lt;53&gt; : tensor&lt;2xi16&gt;}&gt; : () -&gt; tensor&lt;2xi16&gt;
    %1 = "tosa.const"() &lt;{values = dense&lt;10&gt; : tensor&lt;2xi16&gt;}&gt; : () -&gt; tensor&lt;2xi16&gt;
    %2 = tosa.arithmetic_right_shift %1, %0 {round = true} : (tensor&lt;2xi16&gt;, tensor&lt;2xi16&gt;) -&gt; tensor&lt;2xi16&gt;
    %cast = tensor.cast %2 : tensor&lt;2xi16&gt; to tensor&lt;*xi16&gt;
    call @<!-- -->printMemrefI16(%cast) : (tensor&lt;*xi16&gt;) -&gt; ()
    return
  }
}

Command:

/home/workdir/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" | \
/home/workdir/llvm-project-latest/build/bin/mlir-opt -tosa-to-arith \
-one-shot-bufferize="bufferize-function-boundaries=1"  \
-convert-linalg-to-affine-loops \
-lower-affine \
-convert-scf-to-cf \
-convert-to-llvm | \
/home/workdir/llvm-project/build/bin/mlir-runner -e main -entry-point-result=void -shared-libs=/home/workdir/llvm-project/build/lib/libmlir_runner_utils.so

Output:

The results are inconsistent. Possible output include:

[0,  0]

[7134,  -31124]

[10,  0]

[snarang181]

Hi @sweead, are you using the mlir-opt tool from two different copies of the llvm-project?

[CoTinker]

The tosa.arithmetic_right_shift convert to linalg.generic, and the core payload operation is arith.shrsi. As the description of arith.shrsi says:

If the value of the second operand is greater or equal than bitwidth of the first operand, then the operation returns poison.

And the shift amount is 53 in this case, greater than 16.

[CoTinker]

But I'm not sure about the expected behavior of tosa.arithmetic_right_shift when the value of the second operand is greater than or equal to the bit width of the first operand. @lhutton1 @GeorgeARM

[lhutton1]

From the specification, out of range shift values are checked at runtime using a REQUIRE: https://www.mlplatform.org/tosa/tosa_spec_1_0_1.html#_arithmetic_right_shift. If the required condition is not met, the resulting behaviour is undefined. It seems to me the behaviour is similar to arith.shrsi.

Theoretically, in this case, we could verify a constant shift at compile time, but since the shift values don't need to be scalar, I'm not sure it's something we should do.

[CoTinker]

I see, thanks.