================
@@ -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!
----------------
erichkeane wrote:
>It is known that incomplete tag types are the only ones that are problematic
>in this context.
This seems inaccurate to me. CIR doesn't seem to be able to represent(see
here:
https://github.com/llvm/clangir/blob/main/clang/include/clang/CIR/Dialect/IR/CIRTypes.td)
Atomic Types, BitInt types, Block types, and Matrix types upon quick look
(that is perhaps an incomplete list).
The function was written across;
https://github.com/llvm/clangir/commit/101e732565d0e5004c5191b0053eebd8e849cade
and
https://github.com/llvm/clangir/commit/93f55f6d43be394250009013c83d343be7c63f41
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.
Can @lanza and @bcardosolopes chime in and let me know if I'm misinterpreting
the commits there?
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
