[flang-commits] [flang] [mlir] [mlir][Transforms] Dialect conversion: add `originalType` param to materializations (PR #112128)
Matthias Springer via flang-commits
flang-commits at lists.llvm.org
Sun Oct 13 04:10:48 PDT 2024
matthias-springer wrote:
> I see uses of `materializeTargetConversion` within normal conversion patterns where its non-obvious to me as to how that method should now be used.
Ideally, patterns should not call this function at all. It's not really an API violation. I'm just saying that it should not be necessary. The uses that I've seen in upstream MLIR are workarounds around 1:N limitations and they are going to disappear soon. Worst case, users can always pass `originalType = Type()` and ignore this new parameter. (The dialect conversion itself does not require this parameter, only the target materializations may need it; but these are also written by the user.)
> With your example of "v2" replacing "v1", the adaptor of the conversion pattern would then receive "v2", is that right?
Almost. The adaptor receives "v2" only if the type of "v2" is valid according to the pattern's type converter. Otherwise, we will insert another target materialization from "v2" -> "t3" and that value is then passed to the adaptor. That's what's happening during the MemRef->LLVM lowering that I mentioned in the commit message.
The logic for this is in `ConversionPatternRewriterImpl::remapValues`. The implementation has access to the original types; the same is the case for the patterns themselves: they can always get the original types from `op` instead of `adaptor`. However, they may not be able to get original types for ops other than the matched op. (Because they may have to traverse "old" IR which is problematic in a dialect conversion.)
https://github.com/llvm/llvm-project/pull/112128
More information about the flang-commits
mailing list