[Mlir-commits] [mlir] [mlir][Transforms] Dialect Conversion: No target mat. for 1:N replacement (PR #117513)

[Markus Böck]

================
@@ -199,24 +211,34 @@ LLVMTypeConverter::LLVMTypeConverter(MLIRContext *ctx,
     // original memref type.
     return builder.create<UnrealizedConversionCastOp>(loc, resultType, desc)
         .getResult(0);
-  });
-  // Add generic source and target materializations to handle cases where
-  // non-LLVM types persist after an LLVM conversion.
-  addSourceMaterialization([&](OpBuilder &builder, Type resultType,
-                               ValueRange inputs, Location loc) {
-    if (inputs.size() != 1)
-      return Value();
+  };
 
-    return builder.create<UnrealizedConversionCastOp>(loc, resultType, inputs)
-        .getResult(0);
-  });
+  // Argument materializations convert from the new block argument types
+  // (multiple SSA values that make up a memref descriptor) back to the
+  // original block argument type.
+  addArgumentMaterialization(unrakedMemRefMaterialization);
+  addArgumentMaterialization(rankedMemRefMaterialization);
+  addSourceMaterialization(unrakedMemRefMaterialization);
+  addSourceMaterialization(rankedMemRefMaterialization);
+
+  // Bare pointer -> Packed MemRef descriptor
----------------
zero9178 wrote:

I thought about this a lot further and I think the initial version you had is probably the best option for now.

Arguably, the issue here with bare pointers is that we have two different type systems, one where memrefs are bare pointers and one where it is the struct. 
Dealing with multiple type systems is complicated and currently done using a target materialization from the type converter of the pattern consuming the value. From that perspective it makes sense that the LLVM type converter would convert a bare pointer whose original type was a memref to the struct.

Regarding the differences in 1:N and 1:1 conversion, I think one could argue that there is no guarantee given to users as to when and why they *must* exist, just in which situations they may exist.

Sorry for the noise :slightly_smiling_face: 

Am I correct that the flang issue now is one of those cases that happened to work and in your original version continue to "happens to work"?

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