[mlir] Inconsistent output when executing MLIR program with and without `--affine-data-copy-generate --affine-loop-fusion`

[Emilyaxe]

git version: 953838d

system: Ubuntu 18.04.6 LTS

Description:

I am experiencing an inconsistent result when executing the same MLIR program with and without --affine-data-copy-generate --affine-loop-fusion.

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() {
    %4 = "tosa.const"() <{value = dense<-7643> : tensor<1x2x2xi32>}> : () -> tensor<1x2x2xi32>
    %6 = "tosa.const"() <{value = dense<-1782> : tensor<1x2x2xi32>}> : () -> tensor<1x2x2xi32>
    %14 = tosa.cast %6 : (tensor<1x2x2xi32>) -> tensor<1x2x2xf32>
    %40 = tosa.cast %4 : (tensor<1x2x2xi32>) -> tensor<1x2x2xf32>
    %41 = tosa.clamp %14 {max_fp = 1.07374182E+9 : f32, max_int = 1073741823 : i64, min_fp = -1.07374182E+9 : f32, min_int = -1073741824 : i64} : (tensor<1x2x2xf32>) -> tensor<1x2x2xf32>
    %42 = tosa.clamp %40 {max_fp = 1.07374182E+9 : f32, max_int = 1073741823 : i64, min_fp = -1.07374182E+9 : f32, min_int = -1073741824 : i64} : (tensor<1x2x2xf32>) -> tensor<1x2x2xf32>
    %43 = tosa.sub %41, %42 : (tensor<1x2x2xf32>, tensor<1x2x2xf32>) -> tensor<1x2x2xf32>
    %cast = tensor.cast %43 : tensor<1x2x2xf32> to tensor<*xf32>
    call @printMemrefF32(%cast) : (tensor<*xf32>) -> ()
    return
  }
}

2. Command to Run without --affine-data-copy-generate --affine-loop-fusion:

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -tosa-to-arith  --tosa-layerwise-constant-fold  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))"  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt   -convert-arith-to-llvm   -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-affine-loops  -lower-affine  --expand-strided-metadata  -finalize-memref-to-llvm  -convert-math-to-llvm  -convert-scf-to-cf  -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-data-copy-generate --affine-loop-fusion::

[[[5861,    5861],
  [5861,    5861]]]

4. Command to Run With --affine-data-copy-generate --affine-loop-fusion:

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -tosa-to-arith  --tosa-layerwise-constant-fold  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))"  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt   -convert-arith-to-llvm   -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-affine-loops --affine-data-copy-generate="generate-dma=false fast-mem-space=0 skip-non-unit-stride-loops"  --affine-loop-fusion  -lower-affine  --expand-strided-metadata  -finalize-memref-to-llvm  -convert-math-to-llvm  -convert-scf-to-cf  -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-data-copy-generate --affine-loop-fusion:

[[[7643,    7643],
  [7643,    7643]]]

6. Comparation of mlir between with and without --affine-data-copy-generate --affine-loop-fusion:

[llvmbot]

@llvm/issue-subscribers-mlir-affine

Author: None (Emilyaxe)

git version: 953838d

system: Ubuntu 18.04.6 LTS

Description:

I am experiencing an inconsistent result when executing the same MLIR program with and without --affine-data-copy-generate --affine-loop-fusion.

Steps to Reproduce:

1. MLIR Program (a.mlir):

a.mlir:

module {
  func.func private @<!-- -->printMemrefI32(tensor&lt;*xi32&gt;)
  func.func private @<!-- -->printMemrefF32(tensor&lt;*xf32&gt;)
  func.func @<!-- -->main() {
    %4 = "tosa.const"() &lt;{value = dense&lt;-7643&gt; : tensor&lt;1x2x2xi32&gt;}&gt; : () -&gt; tensor&lt;1x2x2xi32&gt;
    %6 = "tosa.const"() &lt;{value = dense&lt;-1782&gt; : tensor&lt;1x2x2xi32&gt;}&gt; : () -&gt; tensor&lt;1x2x2xi32&gt;
    %14 = tosa.cast %6 : (tensor&lt;1x2x2xi32&gt;) -&gt; tensor&lt;1x2x2xf32&gt;
    %40 = tosa.cast %4 : (tensor&lt;1x2x2xi32&gt;) -&gt; tensor&lt;1x2x2xf32&gt;
    %41 = tosa.clamp %14 {max_fp = 1.07374182E+9 : f32, max_int = 1073741823 : i64, min_fp = -1.07374182E+9 : f32, min_int = -1073741824 : i64} : (tensor&lt;1x2x2xf32&gt;) -&gt; tensor&lt;1x2x2xf32&gt;
    %42 = tosa.clamp %40 {max_fp = 1.07374182E+9 : f32, max_int = 1073741823 : i64, min_fp = -1.07374182E+9 : f32, min_int = -1073741824 : i64} : (tensor&lt;1x2x2xf32&gt;) -&gt; tensor&lt;1x2x2xf32&gt;
    %43 = tosa.sub %41, %42 : (tensor&lt;1x2x2xf32&gt;, tensor&lt;1x2x2xf32&gt;) -&gt; tensor&lt;1x2x2xf32&gt;
    %cast = tensor.cast %43 : tensor&lt;1x2x2xf32&gt; to tensor&lt;*xf32&gt;
    call @<!-- -->printMemrefF32(%cast) : (tensor&lt;*xf32&gt;) -&gt; ()
    return
  }
}

2. Command to Run without --affine-data-copy-generate --affine-loop-fusion:

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -tosa-to-arith  --tosa-layerwise-constant-fold  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))"  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt   -convert-arith-to-llvm   -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-affine-loops  -lower-affine  --expand-strided-metadata  -finalize-memref-to-llvm  -convert-math-to-llvm  -convert-scf-to-cf  -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-data-copy-generate --affine-loop-fusion::

[[[5861,    5861],
  [5861,    5861]]]

4. Command to Run With --affine-data-copy-generate --affine-loop-fusion:

/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -tosa-to-arith  --tosa-layerwise-constant-fold  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))"  | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt   -convert-arith-to-llvm   -one-shot-bufferize="bufferize-function-boundaries"  -convert-linalg-to-affine-loops --affine-data-copy-generate="generate-dma=false fast-mem-space=0 skip-non-unit-stride-loops"  --affine-loop-fusion  -lower-affine  --expand-strided-metadata  -finalize-memref-to-llvm  -convert-math-to-llvm  -convert-scf-to-cf  -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-data-copy-generate --affine-loop-fusion:

[[[7643,    7643],
  [7643,    7643]]]

6. Comparation of mlir between with and without --affine-data-copy-generate --affine-loop-fusion:

[Emilyaxe]

I tried to reproduce this issue on history commit versions, and I found these inconsistence results can be reproduced on commit c79ffb0, and cannot be reproduced on the previous commit f5bfc83. Hi @bondhugula , I am sorry for the interruption, but could you please take a moment to review this problem? Thank you!

[bondhugula]

@Emilyaxe Please post the input to affine-data-copy generate or affine fusion if you find one of them to be performing an invalid transformation. What you have above isn't a proper reproducer nor does it establish where the bug is.

[Emilyaxe]

Hi, @bondhugula
I have analyzed this case and identified that the issue may stem from the --affine-loop-fusion pass.

The input IR (before running --affine-loop-fusion) input.txt is correct. However, the output IR (after running --affine-loop-fusion) output.txt contains an invalid transformation.

Specifically, the output IR attempts to access memory (%alloc_18) that has already been deallocated, leading to an incorrect program state.

[bondhugula]

On the provided input IR, with the current main branch, I don't see any dealloc'ed memory being accessed in the output. The report mentions using a commit ID from Dec 10, 2024. There have been several major fixes and improvements to fusion and the underlying utilities in this time frame. In particular, 05a09e6 fixed issues surrounding fusion MDG dependence handling and the handling of dealloc ops and that would have fixed this issue.

OUTPUT:

  %alloc = memref.alloc() {alignment = 64 : i64} : memref<1x2x2xf32>
    %alloc_19 = memref.alloc() : memref<1x2x2xf32>
    affine.for %arg0 = 0 to 2 {
      affine.for %arg1 = 0 to 2 {
        %2 = llvm.intr.minimum(%cst_18, %0) : (f32, f32) -> f32
        %3 = llvm.intr.maximum(%2, %1) : (f32, f32) -> f32
        affine.store %3, %alloc_19[%c0, %arg0, %arg1] : memref<1x2x2xf32>
        %4 = affine.load %alloc_19[0, %arg0, %arg1] : memref<1x2x2xf32>
        affine.store %4, %alloc[0, %arg0, %arg1] : memref<1x2x2xf32>
      }
    }
    memref.dealloc %alloc_19 : memref<1x2x2xf32>
    %alloc_20 = memref.alloc() {alignment = 64 : i64} : memref<1x2x2xf32>
    %alloc_21 = memref.alloc() : memref<1x2x2xf32>
    affine.for %arg0 = 0 to 2 {
      affine.for %arg1 = 0 to 2 {
        %2 = llvm.intr.minimum(%cst, %0) : (f32, f32) -> f32
        %3 = llvm.intr.maximum(%2, %1) : (f32, f32) -> f32
        affine.store %3, %alloc_21[%c0_1, %arg0, %arg1] : memref<1x2x2xf32>
        %4 = affine.load %alloc_21[0, %arg0, %arg1] : memref<1x2x2xf32>
        affine.store %4, %alloc_20[0, %arg0, %arg1] : memref<1x2x2xf32>
      }
    }
    memref.dealloc %alloc_21 : memref<1x2x2xf32>
    %alloc_22 = memref.alloc() {alignment = 64 : i64} : memref<1x2x2xf32>
    %alloc_23 = memref.alloc() : memref<1x2x2xf32>
    %alloc_24 = memref.alloc() : memref<1x2x2xf32>
    %alloc_25 = memref.alloc() : memref<1x2x2xf32>
    affine.for %arg0 = 0 to 2 {
      affine.for %arg1 = 0 to 2 {
        %2 = affine.load %alloc[0, %arg0, %arg1] : memref<1x2x2xf32>
        affine.store %2, %alloc_23[0, %arg0, %arg1] : memref<1x2x2xf32>
        %3 = affine.load %alloc_20[0, %arg0, %arg1] : memref<1x2x2xf32>
        affine.store %3, %alloc_24[0, %arg0, %arg1] : memref<1x2x2xf32>
        %4 = affine.load %alloc_23[0, %arg0, %arg1] : memref<1x2x2xf32>
        %5 = affine.load %alloc_24[0, %arg0, %arg1] : memref<1x2x2xf32>
        %6 = llvm.fsub %4, %5 : f32
        affine.store %6, %alloc_25[%c0_0, %arg0, %arg1] : memref<1x2x2xf32>
        %7 = affine.load %alloc_25[0, %arg0, %arg1] : memref<1x2x2xf32>
        affine.store %7, %alloc_22[0, %arg0, %arg1] : memref<1x2x2xf32>
      }
    }
    memref.dealloc %alloc_25 : memref<1x2x2xf32>
    memref.dealloc %alloc_24 : memref<1x2x2xf32>
    memref.dealloc %alloc_23 : memref<1x2x2xf32>
    %cast = memref.cast %alloc_22 : memref<1x2x2xf32> to memref<*xf32>
    call @printMemrefF32(%cast) : (memref<*xf32>) -> ()
    return
}