================
@@ -22,16 +34,156 @@ using namespace llvm;
namespace cir {
namespace direct {
+struct ConvertCIRToLLVMPass
+ : public mlir::PassWrapper<ConvertCIRToLLVMPass,
+ mlir::OperationPass<mlir::ModuleOp>> {
+ void getDependentDialects(mlir::DialectRegistry ®istry) const override {
+ registry.insert<mlir::BuiltinDialect, mlir::DLTIDialect,
+ mlir::LLVM::LLVMDialect, mlir::func::FuncDialect>();
+ }
+ void runOnOperation() final;
+
+ StringRef getDescription() const override {
+ return "Convert the prepared CIR dialect module to LLVM dialect";
+ }
+
+ StringRef getArgument() const override { return "cir-flat-to-llvm"; }
+};
+
+// This pass requires the CIR to be in a "flat" state. All blocks in each
----------------
bcardosolopes wrote:
Maybe move the comment closer to `ConvertCIRToLLVMPass`? It's a bit misleading
to make it about one specific operation.
> there should be some way of enforcing this constraint
In the case of GlobalOp, there are versions of it that might contain a region.
Usually for other operations that always have regions (IfOp, SwitchOp, ScopeOp,
etc), there's no lowering to LLVM available so you get a hard error if you'd
somehow skip the flattening.
For GlobalOp, perhaps we could emit an error if ctorRegion or dtorRegion are
not empty.
(Another mechanism we could use is to leverage legality:
https://mlir.llvm.org/docs/DialectConversion/#conversion-target, but that
doesn't help with GlobalOp, and for other ops we already get an error, so not
sure it's viable)
> we might eventually be in a situation where non-clang clients
I'd say a bit far-fetched given the dep on AST and other clang bits, but
eventually, it's indeed possible.
https://github.com/llvm/llvm-project/pull/125260
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
