[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