[Mlir-commits] [mlir] [MLIR] Add options to generate-runtime-verification to enable faster pass running (PR #160331)

[Hanchenng Wu]

================
@@ -36,10 +44,46 @@ void GenerateRuntimeVerificationPass::runOnOperation() {
     ops.push_back(verifiableOp);
   });
 
+  // Create error message generator based on verboseLevel
----------------
HanchengWu wrote:

Hi, sorry for the confusion. Please see my below explaination.

**Assume Input mlir is below, with a simple memref.copy, let's name it "OP X":**

[OP X]  memref.copy %subview_3315, %subview_3326 : memref<?x4xf32, strided<[4, 1]>> to memref<?x4xf32, strided<[?, 1], offset: ?>>

**Then, at generate runtime verification pass running:**

[CHECK INSERTED for OP X] cf.assert %17892, "ERROR: Runtime op verification failed \n memref.copy(%36435, %36605) : (memref<?x4xf32, strided<[4, 1]>>, memref<?x4xf32, strided<[?, 1], offset: ?>>) \n size of 0-th source/target dim does not match^\0ALocation: loc(\22ssd_mobilenet_v2.standard.mlir\22:33423:5)"
[OP X in MEMORY]  memref.copy %UNKONWN_NAME, %UNKNOWN_NAME : memref<?x4xf32, strided<[4, 1]>> to memref<?x4xf32, strided<[?, 1], offset: ?>>

We see that we inserted a check to see if src/target dim mathces before the memref.copy operation.
Notice that for the ERROR msg, we call "op->print()" to get the full string of the OP X.
The full string returned is "memref.copy(%36435, %36605) ...."


**Now, we emit the mlir to an output file after runtime verification pass finished, it will look like below:**

[CHECK BEING EMITTED] cf.assert %17892, "ERROR: Runtime op verification failed \n memref.copy(%36435, %36605) : (memref<?x4xf32, strided<[4, 1]>>, memref<?x4xf32, strided<[?, 1], offset: ?>>) \n size of 0-th source/target dim does not match^\0ALocation: loc(\22ssd_mobilenet_v2.standard.mlir\22:33423:5)"
[OP X BEING EMITTED]  memref.copy %subview_22330, %subview_22448 : memref<?x4xf32, strided<[4, 1]>> to memref<?x4xf32, strided<[?, 1], offset: ?>>

We see that the operation string used in the CHECK and the actual string of the operation following the CHECK is different.
The string that "op->print()" returned for OP X to be used inside the ERROR message is:
memref.copy(%36435, %36605) : ......

The string that is emitted for OP X when we dump the mlir to an output file after the pass finishes is:
memref.copy %subview_22330, %subview_22448 : ......

We see different operand names are used for the same operation. I misunderstood this, as I thought these operands names would be the same. What I guessed about how ArmState works is: if we have already assigned SSA names to these operands, these names will be picked up and reused by later SSA analysis at emitting. But obviously this is wrong as shown above. The emitter used totally different operands name for the same op, as compared to what's used in the error message. 

This said, the operation string used in the ERROR message is not informative at all. The operands names it shows are neigher used in the input mlir, nor are they used in the actual operation if we dump the after-pass mlir to an output file.

Thus, I think we can consider remove verbose 3 in a later update.

https://github.com/llvm/llvm-project/pull/160331