MLIR module verification error in the affine for loop

I generated a bicg loop (which is a benchmark from polybench) in affine dialect.
The original code is as follows:

module {
  func @bicg(%arg0: memref<32x32xf64>, %arg1: memref<32xf64>, %arg2: memref<32xf64>, %arg3: memref<32xf64>, %arg4: memref<32xf64>) {
    affine.for %arg5 = 0 to 32 {
      affine.for %arg6 = 0 to 32 {
        %0 = affine.load %arg0[%arg5, %arg6] : memref<32x32xf64>
        %1 = affine.load %arg1[%arg6] : memref<32xf64>
        %2 = arith.mulf %0, %1 : f64
        %3 = affine.load %arg2[%arg5] : memref<32xf64>
        %4 = arith.addf %2, %3 : f64
        affine.store %4, %arg2[%arg5] : memref<32xf64>
        %5 = affine.load %arg0[%arg5, %arg6] : memref<32x32xf64>
        %6 = affine.load %arg3[%arg5] : memref<32xf64>
        %7 = arith.mulf %5, %6 : f64
        %8 = affine.load %arg4[%arg6] : memref<32xf64>
        %9 = arith.addf %7, %8 : f64
        affine.store %9, %arg4[%arg6] : memref<32xf64>
      }
    }
    return
  }
}

In order to test the code’s latency after loop transformations, I split the code into the following format and an error occurs:

if (failed(mlir::verify(*module))) {
    module->emitError("module verification error");
    module->dump();
}
error: operand #1 does not dominate this use
error: module verification error
module {
func @bicg(%arg0: memref<32x32xf64>, %arg1: memref<32xf64>, %arg2: memref<32xf64>, %arg3: memref<32xf64>, %arg4: memref<32xf64>) { 
affine.for %arg5 = 0 to 32 {
      affine.for %arg6 = 0 to 32 {
        %0 = affine.load %arg0[%arg5, %arg6] : memref<32x32xf64>
        %1 = affine.load %arg3[%arg5] : memref<32xf64>
        %2 = arith.mulf %0, %1 : f64
        %3 = affine.load %arg4[%arg6] : memref<32xf64>
        %4 = arith.addf %2, %3 : f64
        affine.store %4, %arg4[%arg6] : memref<32xf64>
      }
    }
    affine.for %arg5 = 0 to 32 {
      affine.for %arg6 = 0 to 32 {
        %0 = affine.load %arg0[%arg5, %arg6] : memref<32x32xf64>
        %1 = affine.load %arg1[%arg6] : memref<32xf64>
        %2 = arith.mulf %0, %1 : f64
        %3 = affine.load %arg2[%arg5] : memref<32xf64>
        %4 = arith.addf %2, %3 : f64
        affine.store %4, %arg2[%arg5] : memref<32xf64>
      }
    }
    return
  }
}

Acutally I can not see any “dominance errors” in the second picture.
So I want to know what leads to such an error and what should I do to aviod such errors. Thanks!

I forget how this situation would look when printed, but it is possible that the %arg5 and %arg6 values are pointing to the same value rather than being new values like you are expecting. In fact, I believe they should have different names (arg5, arg6 followed by arg7, arg8). This then results in a dominance error when one pair of loops is using values defined by the other loops.

1 Like

Please paste your code as text, not as pictures. This makes it at least readable and lets whoever wants to help you copy it into their own flow.

Thanks for your advise ! I have edited my question.

The IR as written is valid, it can roundtrip. So what may be happening is that the second region somehow uses the values defined in the first region, which is invalid. The counter for visible names is reset when you leave the region, so %0 appears in both but refers to different values. In, for example, arith.mulf %0, %1, you don’t actually know which of the two %0 is being used. The best way is to resolve this is to attach a debugger and to see which pointers are associated to each of the values.

1 Like

The error message should be quite explicit about it, can you post it entirely please?

Here is the error message:

That seems unexpected to me: there is no location emitted here and more importantly we’re emitting a note attached to the diagnostic that is much more descriptive for this failure (see the code here).

Do you have a reproducer I could try?

I was also expecting a more detailed error message but actually error: operand #1 does not dominate this use was all I got. I’m sorry that I can’t provide any reproducer at the moment. Since the IR itself is valid, I’ll just leave the error alone for the moment. Thank you for your help!