[mlir] Inconsistent output when executing MLIR program with and without --scf-for-loop-peeling="peel-front"

[Emilyaxe]

git version: adf892d

system: Ubuntu 18.04.6 LTS

Description:

I am experiencing an inconsistent result when executing the same MLIR program with and without the --scf-for-loop-peeling="peel-front".

Steps to Reproduce:

1. MLIR Program (a.mlir):

a.mlir:

module {
  func.func private @printMemrefI32(tensor<*xi32>)
  func.func private @printMemrefF32(tensor<*xf32>)
  func.func @main() {
    %0 = "tosa.const"() <{value = dense<3380> : tensor<1x6x6xi32>}> : () -> tensor<1x6x6xi32>
    %1 = tosa.cast %0 : (tensor<1x6x6xi32>) -> tensor<1x6x6xf32>
    %2 = tosa.erf %1 : (tensor<1x6x6xf32>) -> tensor<1x6x6xf32>
    %cast = tensor.cast %2 : tensor<1x6x6xf32> to tensor<*xf32>
    call @printMemrefF32(%cast) : (tensor<*xf32>) -> ()
    return
  }
}

2. Command to Run Without --scf-for-loop-peeling="peel-front":

 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))"  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt  -tosa-to-arith  -test-math-polynomial-approximation -convert-arith-to-llvm  -convert-math-to-llvm  -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-loops  -finalize-memref-to-llvm  -convert-scf-to-cf  -convert-arith-to-llvm  -convert-cf-to-llvm  -convert-func-to-llvm  -reconcile-unrealized-casts | /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 --scf-for-loop-peeling="peel-front"::

[[[1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1]]]

4. Command to Run With --scf-for-loop-peeling="peel-front"::

 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt  -tosa-to-arith  -test-math-polynomial-approximation -convert-arith-to-llvm  -convert-math-to-llvm  -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-loops  -finalize-memref-to-llvm --scf-for-loop-peeling="peel-front"  -convert-scf-to-cf  -convert-arith-to-llvm  -convert-cf-to-llvm  -convert-func-to-llvm  -reconcile-unrealized-casts | /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 --scf-for-loop-peeling="peel-front"::

[[[1,    3.07879e-41,    0,    0,    -2.17439e-08,    3.07879e-41],
  [1,    1,    1,    1,    1,    1],
  [1,    1,    1,    1,    1,    1],
  [1,    1,    1,    1,    1,    1],
  [1,    1,    1,    1,    1,    1],
  [1,    1,    1,    1,    1,    1]]]

[christopherbate]

I suspect the difference has more to do with the relative ordering of test-math-polynomial-approximation and math-to-llvm in the two commands given.

[Emilyaxe]

I suspect the difference has more to do with the relative ordering of test-math-polynomial-approximation and math-to-llvm in the two commands given.

I use the same ordering of test-math-polynomial-approximation and math-to-llvm in two commands, with the only difference being the presence or absence of the --scf-for-loop-peeling="peel-front" option. The inconsistency also exists.

1. Command with --scf-for-loop-peeling="peel-front" : /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -tosa-to-arith -test-math-polynomial-approximation -convert-arith-to-llvm -convert-math-to-llvm -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-loops -finalize-memref-to-llvm --scf-for-loop-peeling="peel-front" -convert-scf-to-cf -convert-arith-to-llvm -convert-func-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | /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
   Output

[[[1,    3.0652e-41,    -9.13817e-11,    3.0652e-41,    -9.13817e-11,    3.0652e-41], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1]]]

2. Command without --scf-for-loop-peeling="peel-front" : /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -tosa-to-arith -test-math-polynomial-approximation -convert-arith-to-llvm -convert-math-to-llvm -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-loops -finalize-memref-to-llvm -convert-scf-to-cf -convert-arith-to-llvm -convert-func-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | /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
   Output

[[[1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1], 
  [1,    1,    1,    1,    1,    1]]]

[Emilyaxe]

@christopherbate Sorry to disturb you, but I was wondering if this might be a bug related to the --scf-for-loop-peeling="peel-front" option. After running with this pass, I checked the resulting MLIR and noticed that a variable was miscompiled.

[Emilyaxe]

Hello @yzhang93, sorry to disturb you, but I wanted to discuss a potential issue that might be related to the --scf-for-loop-peeling="peel-front" option. When peeling the first iteration, all upperBound values in the forOp are replaced with splitBound. However, this replacement incorrectly occurs even for inner loops that share the same upperBound as their enclosing loops, potentially leading to miscompilation.

[Emilyaxe]

Hello @MaheshRavishankar, @dcaballe, @antiagainst,
I apologize for the interruption. I've noticed an issue with the changes in commit bd6a245 which you have previously reviewed. Could you please take a moment to look into this when you have some time? Thank you for your assistance!

[yzhang93]

Hello @yzhang93, sorry to disturb you, but I wanted to discuss a potential issue that might be related to the --scf-for-loop-peeling="peel-front" option. When peeling the first iteration, all upperBound values in the forOp are replaced with splitBound. However, this replacement incorrectly occurs even for inner loops that share the same upperBound as their enclosing loops, potentially leading to miscompilation.

Hi @Emilyaxe, sorry for the late response. I just saw this issue today.

I think your exploration makes sense. With map.map() method, all upperBound values in the forOp are replaced with splitBound. Previously, I had a old version without using IRMapping, please refer to this a3c8551#diff-a28533cbcf9fa000b1a4fc3ed87c811a64f01759d763cfb3c0a58a518b9f9f63R250-R256.

  // Peel the first iteration.
  firstIteration = cast<ForOp>(b.clone(*forOp.getOperation()));
  firstIteration.getUpperBoundMutable().assign(splitBound);

  // Update main loop with new lower bound.
  forOp.getInitArgsMutable().assign(firstIteration->getResults());
  b.modifyOpInPlace(
      forOp, [&]() { forOp.getLowerBoundMutable().assign(splitBound); });

This should get rid of the problem. Could you please give it a try?