================
@@ -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 think it's totally fine to be conservative about assumptions, we need asserts 
for both things that are NYI but also for things we assume as invariants, IMO 
the more the merrier cause it's easier to catch miscompilations.

> Neither of which mention those types specifically? It seems it USED to have 
> an assert for not-tag-type, though it isn't clear that the authors considered 
> the above types.

I don't remember the full context anymore, but assertion on a assumed invariant 
in the incubator to be even more protective also sounds good to me (guess 
running the tests upon such change will give us the final answer).

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

Reply via email to