While converting an operation opA in dialect A to dialect B in MLIR, all the operands of opA are converted to dialect B and provided to the conversion function (convertOpA) for opA. In convertOpA, is it safe to assume that the definingOp of the converted operands are also currently in dialect B?
The operands may or may not have been converted. But if you need them to be, you can make that a precondition of the pattern.
1 Like
If you are using conversion patterns, the values you get in the “operands” field are guaranteed to have legal types according to the type converter configuration. There is no guarantee that they will be coming directly from the converted defining op though, they may be coming from unrealized casts.
3 Likes
I wanted to check whether the definingOp is an Undef Operation.
I was initially thinking, in the conversion pattern, I could access the operand’s (provided to the pattern) definingOp and then compare it with the LLVM::UndefOp. But from what you say it is probably incorrect in some cases. Will it be correct to access the originalOperands through the Operation and then check whether it is a fir::UndefOp?
This is part of the following patch : âš™ D128017 [Flang] Fixes for XArrayCoorOp.
In conversion patterns, it should be, they don’t erase the original operation immediately. Note that the operation may be modified in-place though (attributes, operands changed by some patterns, but not the operation name).
1 Like