[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