================
@@ -2171,8 +2171,53 @@ mlir::Attribute
CIRGenModule::getAddrOfRTTIDescriptor(mlir::Location loc,
if (!shouldEmitRTTI(forEh))
return builder.getConstNullPtrAttr(builder.getUInt8PtrTy());
- errorNYI(loc, "getAddrOfRTTIDescriptor");
- return mlir::Attribute();
+ if (forEh && ty->isObjCObjectPointerType() &&
+ langOpts.ObjCRuntime.isGNUFamily()) {
+ errorNYI(loc, "getAddrOfRTTIDescriptor: Objc PtrType & Objc RT GUN");
+ return {};
+ }
+
+ return getCXXABI().getAddrOfRTTIDescriptor(loc, ty);
+}
+
+/// TODO(cir): once we have cir.module, add this as a convenience method there.
+///
+/// Look up the specified global in the module symbol table.
+/// 1. If it does not exist, add a declaration of the global and return it.
+/// 2. Else, the global exists but has the wrong type: return the function
+/// with a constantexpr cast to the right type.
+/// 3. Finally, if the existing global is the correct declaration, return the
+/// existing global.
+cir::GlobalOp CIRGenModule::getOrInsertGlobal(
+ mlir::Location loc, StringRef name, mlir::Type ty,
+ llvm::function_ref<cir::GlobalOp()> createGlobalCallback) {
+ // See if we have a definition for the specified global already.
+ auto gv = dyn_cast_or_null<cir::GlobalOp>(getGlobalValue(name));
----------------
andykaylor wrote:
The `dyn_cast_or_null` here worries me. What happens if `getGlobalValue(name)`
returns a non-null operation, but it isn't a `cir::GlobalOp`? That shouldn't
happen, but if it does this code will try to create a global that conflicts
with the existing operation. In `CIRGenModule::getOrCreateCIRGlobal` we have a
check that will produce a diagnostic if this happens.
https://github.com/llvm/llvm-project/pull/160002
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
