[Mlir-commits] [mlir] [mlir][Transforms] `OneToNTypeConversion.cpp`: Fix invalid IR (PR #77922)

[Matthias Springer]

matthias-springer wrote:

I've been fixing failures throughout the last weeks. We're almost there.

> What's the plan for enabling MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS as part of CI? Should there not be a plan to enable it eventually, would there be any way to test the code otherwise?

You can always enable these checks manually with this CMake option: `-DMLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS=ON`. This will slow down the tests (`check-mlir`) considerably. They take about 5-8 minutes on my machine. I have not looked at performance so far, but we should be able to speed up the extra checks by being more selective about which IR is verified.

> The proposed fix is valid because if the previous result types are converted to "no result types", then there cannot be any consumers of the results, so no consumer need any cast.

Correct.

There's one more tricky case in the 1-to-n conversion test cases. There are 3 patterns for converting function signatures, one for each of these ops: `func.func`, `func.call`, `func.return`. After applying the `func.func` pattern, the IR fails to verify because the `func.call` ops have not been updated yet. (But it verifies eventually, when the entire IR has been processed.) I'm not really sure what to do with that. In a sense, the `func.call` verifier does not adhere to MLIR coding guidelines because it verifies a non-local property.

Note: We don't have this issue with the regular dialect conversion because there no "expensive checks" to verify the IR after each conversion pattern application. We only do that for rewrite patterns.

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