[flang-commits] [flang] [mlir] [mlir][Transforms] Support 1:N mappings in `ConversionValueMapping` (PR #116524)
Matthias Springer via flang-commits
flang-commits at lists.llvm.org
Tue Dec 24 01:39:32 PST 2024
================
@@ -1478,34 +1497,12 @@ Value ConversionPatternRewriterImpl::findOrBuildReplacementValue(
}
Value castValue = buildUnresolvedMaterialization(
MaterializationKind::Source, computeInsertPoint(repl), value.getLoc(),
----------------
matthias-springer wrote:
Both in this case, and in the `remapValues` above, we could choose to *not* store the materialization value in the mapping. That would mean that we create a new materialization each time, which would mean there's some compile time overhead. (The extra ops would disappear again when running CSE.) We could do that for N:* materializations only, which are less common. Long term, I'd like to do that as part of the One-Shot Dialect Conversion effort. I'm hesitating because:
1. MemRef -> LLVM is a 1:N replacement, so N:* materializations may be more common than I'm thinking.
2. 1:N and 1:1 would not be handled in a uniform way.
3. On the One-Shot Dialect Conversion RFC, we talked about "pooling" `unrealized_conversion_cast` ops to avoid the performance overhead to create/destroy ops. That's not part of this PR (and I'd rather put that as a separate PR).
https://github.com/llvm/llvm-project/pull/116524
More information about the flang-commits
mailing list