[clang] [CIR] Upstream support for operator assign (PR #145979)

Erich Keane via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 27 10:56:03 PDT 2025


================
@@ -258,6 +258,30 @@ void CIRGenFunction::emitDelegateCXXConstructorCall(
                          /*Delegating=*/true, thisAddr, delegateArgs, loc);
 }
 
+void CIRGenFunction::emitImplicitAssignmentOperatorBody(FunctionArgList &args) {
+  const auto *assignOp = cast<CXXMethodDecl>(curGD.getDecl());
+  const Stmt *rootS = assignOp->getBody();
+  assert(isa<CompoundStmt>(rootS) &&
+         "Body of an implicit assignment operator should be compound stmt.");
+  const auto *rootCS = cast<CompoundStmt>(rootS);
+
+  // LexicalScope Scope(*this, RootCS->getSourceRange());
+  // FIXME(cir): add all of the below under a new scope.
+
+  assert(!cir::MissingFeatures::incrementProfileCounter());
+  // Classic codegen uses a special class to attempt to replace member
+  // initializers with memcpy. We could possibly defer that to the
+  // lowering or optimization phases to keep the memory accesses more
+  // explicit. For now, we don't insert memcpy at all, though in some
+  // cases the AST contains a call to memcpy.
----------------
erichkeane wrote:

IMO, it shouldn't.  CIR should be the one doing the ->memcpy translation, not the FE.  Classic-codegen does it because it has to, CIR-codegen,  shouldn't.

Note the above is a general comment, not on this patch/shouldn't block this patch.  Point is in general, the premature-optimization of 'implement as memcpy' is going to inhibit useful opt opportunities and reduce the expressiveness of the IR.  We should avoid that if possible.

https://github.com/llvm/llvm-project/pull/145979


More information about the cfe-commits mailing list