================
@@ -18,6 +21,87 @@ mlir::MLIRContext &CIRGenTypes::getMLIRContext() const {
return *builder.getContext();
}
+/// Return true if the specified type in a function parameter or result
position
+/// can be converted to a CIR type at this point. This boils down to being
+/// whether it is complete, as well as whether we've temporarily deferred
+/// expanding the type because we're in a recursive context.
+bool CIRGenTypes::isFuncParamTypeConvertible(clang::QualType type) {
+ // Some ABIs cannot have their member pointers represented in LLVM IR unless
+ // certain circumstances have been reached.
+ assert(!type->getAs<MemberPointerType>() && "NYI");
+
+ // If this isn't a tagged type, we can convert it!
----------------
bcardosolopes wrote:
I don't remember the details on why it was necessary at the time to deviate -
so I just made this be equivalent to traditional codegen and everything passes:
https://github.com/llvm/clangir/commit/04d7dcfb2582753f3eccbf01ec900d60297cbf4b
That said, I don't think we need to introduce any asserts here, can't get
better than OG for the sake of completeness. Not supported types will crash
given the other mechanisms David mentioned, but the recursive logic is sound
with pre-existing work.
Unless Erich has any other concerns, this LGTM to land.
https://github.com/llvm/llvm-project/pull/120484
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
