[Mlir-commits] [mlir] [mlir][Transforms] Dialect conversion: Context-aware type conversions (PR #140434)

[Hongren Zheng]

ZenithalHourlyRate wrote:

Happy to see this! I think this API is general enough. I would like to list scenarios downstream project has encountered where `Type <-> Value` correspondence would occur or there is no such correspondence, so we can discuss with more care.

1. Value that has DefiningOp (handled in this PR)
2. Value that is BlockArgument (find parent Block/Region/Op, looking "up" in the IR hierarchy)
3. Block Return Type (should find Block Terminator, looking "down" in the hierarchy; or should it find parent Block?)
4. function signature without entry block (user should take care of it)
5. function signature with entry block (looking "down" in the hierarchy into its entry block, for both argument and return type)

The context for a Type is defined either up or down in the hierarchy, which I think is not so clear and may worth some clarification.  Also, typically the context is actually an `Attribute`, which now may be arbitrarily discarded (some discussion in #127772).

I am a little bit concerned about the safety of accessing the context for `Value` during dialect conversion. The context finding behavior, ought to be safe (theoretically a Value should only find the original IR during conversion), was unsafe actually. The complexity roots from the Block. For Operations we kept both copies during conversion so a Value should find the original Op, but Block are not so well maintained in that things inside a block may not access the original Block depending on the conversion order.

1. As originally mentioned in https://github.com/google/heir/pull/1527, a Value of BlockArgument could have no parent op after block signature conversion as the block is unlinked, resulting in segfault when trying to access one. Type/Value legality check is also affected.
2. The order of conversion now matters because the context is defined both up/down the hierarchy. ParentOp (like function signature) converted the first or child (like block signature) converted the first will affect whether a Value is able to find its context. This kind of bug is quite hard to debug for user. 
3. Such unlinked behavior could be resolved by lookup the internal Mapping, but currently we are unable to do so.


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