[Mlir-commits] [mlir] [mlir][LLVM] Add the `ConvertToLLVMAttrInterface` and `ConvertToLLVMOpInterface` interfaces (PR #99566)

Fabian Mora llvmlistbot at llvm.org
Fri Jul 26 08:33:15 PDT 2024


================
@@ -30,3 +30,20 @@ void mlir::populateConversionTargetFromOperation(
                                                    patterns);
   });
 }
+
+void mlir::populateOpConvertToLLVMConversionPatterns(
+    Operation *op, ConversionTarget &target, LLVMTypeConverter &typeConverter,
+    RewritePatternSet &patterns) {
+  auto iface = dyn_cast<ConvertToLLVMOpInterface>(op);
+  if (!iface)
+    return;
+  SmallVector<ConvertToLLVMAttrInterface, 12> attrs;
+  iface.getConvertToLLVMConversionAttrs(attrs);
+  for (ConvertToLLVMAttrInterface attr : attrs)
+    attr.populateConvertToLLVMConversionPatterns(target, typeConverter,
+                                                 patterns);
+}
----------------
fabianmcg wrote:

I think there's a missing `CompilationUnitOpInterface` abstraction in general in MLIR, which would clarify the semantics in this case, because one could search the nearest op with the interface (or trait).

However, I also think it is reasonable for users to expect that a pass might perform different actions depending on the op context. In the sense that `convert-to-llvm` applied to a function won't update `func.func`, but if applied to `module` containing `func.func` it will be converted to `llvm.func`.

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


More information about the Mlir-commits mailing list