[mlir] Inconsistent output when executing MLIR program with `affine-parallelize` and `--affine-super-vectorize`

[anonymoususer-1]

git version: ff939b0

system: Ubuntu 18.04.6 LTS

Description:

I am experiencing an inconsistent result when executing the same MLIR program with and without affine-parallelize and --affine-super-vectorize.
The output becomes correct when either of these two options is removed, so I'm unsure which optimization contains the bug.

Steps to Reproduce:

1. MLIR Program (tosa.mlir):

tosa.mlir:

module {
  func.func private @printMemrefI32(tensor<*xi32>)
  func.func private @printMemrefF32(tensor<*xf32>)
  func.func @main() {
    %0 = "tosa.const"() <{value = dense<[0, 2, 1]> : tensor<3xi32>}> : () -> tensor<3xi32>
    %1 = "tosa.const"() <{value = dense<-12> : tensor<1x4x21xi32>}> : () -> tensor<1x4x21xi32>
    %2 = "tosa.const"() <{value = dense<1676> : tensor<1x4x21xi32>}> : () -> tensor<1x4x21xi32>
    %3 = "tosa.const"() <{value = dense<-10> : tensor<1x4x21xi32>}> : () -> tensor<1x4x21xi32>
    %4 = tosa.abs %2 : (tensor<1x4x21xi32>) -> tensor<1x4x21xi32>
    %5 = tosa.clamp %4 {max_fp = 1.600000e+01 : f32, max_int = 16 : i64, min_fp = 0.000000e+00 : f32, min_int = 0 : i64} : (tensor<1x4x21xi32>) -> tensor<1x4x21xi32>
    %6 = tosa.arithmetic_right_shift %2, %5 {round = true} : (tensor<1x4x21xi32>, tensor<1x4x21xi32>) -> tensor<1x4x21xi32>
    %7 = tosa.minimum %6, %1 : (tensor<1x4x21xi32>, tensor<1x4x21xi32>) -> tensor<1x4x21xi32>
    %8 = tosa.transpose %3, %0 : (tensor<1x4x21xi32>, tensor<3xi32>) -> tensor<1x21x4xi32>
    %9 = tosa.matmul %7, %8 : (tensor<1x4x21xi32>, tensor<1x21x4xi32>) -> tensor<1x4x4xi32>
    %cast = tensor.cast %9 : tensor<1x4x4xi32> to tensor<*xi32>
    call @printMemrefI32(%cast) : (tensor<*xi32>) -> ()
    return
  }
}

2. Command to Run without affine-parallelize and --affine-super-vectorize :

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt tosa.mlir \
-pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt\
--linalg-generalize-named-ops  -tosa-to-arith  -convert-math-to-llvm    --test-linalg-elementwise-fusion-patterns="fuse-generic-ops-control" \
-one-shot-bufferize="bufferize-function-boundaries"    -convert-arith-to-llvm     -convert-linalg-to-affine-loops  \
-convert-vector-to-scf    -convert-arith-to-llvm    --affine-loop-coalescing  -convert-vector-to-scf    -convert-vector-to-llvm  \
-convert-math-to-llvm -convert-arith-to-llvm   -lower-affine     -convert-scf-to-cf   -finalize-memref-to-llvm \
-convert-func-to-llvm  -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so\
--shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so

3. Output without affine-parallelize and --affine-super-vectorize ::

[[[2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520]]]

4. Command to Run with affine-parallelize and --affine-super-vectorize :

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt tosa.mlir  -pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))"\
| /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt     --linalg-generalize-named-ops   -tosa-to-arith  -convert-math-to-llvm \
--test-linalg-elementwise-fusion-patterns="fuse-generic-ops-control"   -one-shot-bufferize="bufferize-function-boundaries"    -convert-arith-to-llvm \
-convert-linalg-to-affine-loops  --affine-parallelize    -convert-vector-to-scf    -convert-arith-to-llvm    --affine-loop-coalescing  -convert-vector-to-scf \ 
--affine-super-vectorize="virtual-vector-size=128 test-fastest-varying=0 vectorize-reductions=true"      -convert-vector-to-llvm     -convert-math-to-llvm \
-convert-arith-to-llvm       -lower-affine     -convert-scf-to-cf   -finalize-memref-to-llvm  -convert-func-to-llvm  -reconcile-unrealized-casts \
| timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so \
--shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so

5. Output with affine-parallelize and --affine-super-vectorize :

[[[120,    120,    120,    120],
  [120,    120,    120,    120],
  [120,    120,    120,    120],
  [120,    120,    120,    120]]]

[llvmbot]

@llvm/issue-subscribers-mlir-affine

Author: None (Emilyaxe)

git version: ff939b0

system: Ubuntu 18.04.6 LTS

Description:

I am experiencing an inconsistent result when executing the same MLIR program with and without affine-parallelize and --affine-super-vectorize.
The output becomes correct when either of these two options is removed, so I'm unsure which optimization contains the bug.

Steps to Reproduce:

1. MLIR Program (tosa.mlir):

tosa.mlir:

module {
  func.func private @<!-- -->printMemrefI32(tensor&lt;*xi32&gt;)
  func.func private @<!-- -->printMemrefF32(tensor&lt;*xf32&gt;)
  func.func @<!-- -->main() {
    %0 = "tosa.const"() &lt;{value = dense&lt;[0, 2, 1]&gt; : tensor&lt;3xi32&gt;}&gt; : () -&gt; tensor&lt;3xi32&gt;
    %1 = "tosa.const"() &lt;{value = dense&lt;-12&gt; : tensor&lt;1x4x21xi32&gt;}&gt; : () -&gt; tensor&lt;1x4x21xi32&gt;
    %2 = "tosa.const"() &lt;{value = dense&lt;1676&gt; : tensor&lt;1x4x21xi32&gt;}&gt; : () -&gt; tensor&lt;1x4x21xi32&gt;
    %3 = "tosa.const"() &lt;{value = dense&lt;-10&gt; : tensor&lt;1x4x21xi32&gt;}&gt; : () -&gt; tensor&lt;1x4x21xi32&gt;
    %4 = tosa.abs %2 : (tensor&lt;1x4x21xi32&gt;) -&gt; tensor&lt;1x4x21xi32&gt;
    %5 = tosa.clamp %4 {max_fp = 1.600000e+01 : f32, max_int = 16 : i64, min_fp = 0.000000e+00 : f32, min_int = 0 : i64} : (tensor&lt;1x4x21xi32&gt;) -&gt; tensor&lt;1x4x21xi32&gt;
    %6 = tosa.arithmetic_right_shift %2, %5 {round = true} : (tensor&lt;1x4x21xi32&gt;, tensor&lt;1x4x21xi32&gt;) -&gt; tensor&lt;1x4x21xi32&gt;
    %7 = tosa.minimum %6, %1 : (tensor&lt;1x4x21xi32&gt;, tensor&lt;1x4x21xi32&gt;) -&gt; tensor&lt;1x4x21xi32&gt;
    %8 = tosa.transpose %3, %0 : (tensor&lt;1x4x21xi32&gt;, tensor&lt;3xi32&gt;) -&gt; tensor&lt;1x21x4xi32&gt;
    %9 = tosa.matmul %7, %8 : (tensor&lt;1x4x21xi32&gt;, tensor&lt;1x21x4xi32&gt;) -&gt; tensor&lt;1x4x4xi32&gt;
    %cast = tensor.cast %9 : tensor&lt;1x4x4xi32&gt; to tensor&lt;*xi32&gt;
    call @<!-- -->printMemrefI32(%cast) : (tensor&lt;*xi32&gt;) -&gt; ()
    return
  }
}

2. Command to Run without affine-parallelize and --affine-super-vectorize :

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt tosa.mlir  -pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt     --linalg-generalize-named-ops   -tosa-to-arith  -convert-math-to-llvm    --test-linalg-elementwise-fusion-patterns="fuse-generic-ops-control"   -one-shot-bufferize="bufferize-function-boundaries"    -convert-arith-to-llvm     -convert-linalg-to-affine-loops   -convert-vector-to-scf    -convert-arith-to-llvm    --affine-loop-coalescing  -convert-vector-to-scf      -convert-vector-to-llvm     -convert-math-to-llvm       -convert-arith-to-llvm       -lower-affine     -convert-scf-to-cf   -finalize-memref-to-llvm  -convert-func-to-llvm  -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so

3. Output without affine-parallelize and --affine-super-vectorize ::

[[[2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520],
  [2520,    2520,    2520,    2520]]]

4. Command to Run with affine-parallelize and --affine-super-vectorize :

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt tosa.mlir  -pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt     --linalg-generalize-named-ops   -tosa-to-arith  -convert-math-to-llvm    --test-linalg-elementwise-fusion-patterns="fuse-generic-ops-control"   -one-shot-bufferize="bufferize-function-boundaries"    -convert-arith-to-llvm     -convert-linalg-to-affine-loops  --affine-parallelize    -convert-vector-to-scf    -convert-arith-to-llvm    --affine-loop-coalescing  -convert-vector-to-scf   --affine-super-vectorize="virtual-vector-size=128 test-fastest-varying=0 vectorize-reductions=true"      -convert-vector-to-llvm     -convert-math-to-llvm       -convert-arith-to-llvm       -lower-affine     -convert-scf-to-cf   -finalize-memref-to-llvm  -convert-func-to-llvm  -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so

5. Output with affine-parallelize and --affine-super-vectorize :

[[[120,    120,    120,    120],
  [120,    120,    120,    120],
  [120,    120,    120,    120],
  [120,    120,    120,    120]]]

[anonymoususer-1]

I tried reproducing this issue using historical commit versions and found that the inconsistent results occur with commit 181d960 (which results in 120), but not with the previous commit b6c453c (which results in 2520).

I suspect this issue might be related to the --affine-super-vectorize="virtual-vector-size=128 test-fastest-varying=0 vectorize-reductions=true" option.

The difference in the IR between commit 181d960 and commit b6c453c after running the --affine-super-vectorize="virtual-vector-size=128 test-fastest-varying=0 vectorize-reductions=true" pass is as follows:

Hi @Hsiangkai , I am sorry to disturb you, but could you please take a moment to review this problem? Thank you!

[bondhugula]

@Emilyaxe Please don't provide reproducers that require entire pass pipelines to be run because that doesn't establish where the bug is. Instead, identifying the pass that generates the incorrect IR and minimizing its test case input to reproduce will help.

[bondhugula]

The report only includes the diff in IR after a long pass pipeline specification instead of an input IR to the pass with the potential bug (and the incorrect output observed). This doesn't establish where the bug is or allow one to reproduce it. Please reopen with this info if the issue is still present.