[clang] [CIR] Upstream RTTI Builder & RTTI for VTable Definitions (PR #160002)

[Andy Kaylor via cfe-commits]

================
@@ -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