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

[Andy Kaylor via cfe-commits]

================
@@ -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.
----------------
andykaylor wrote:

Do you mean that the front end shouldn't be putting the memcpy call in the AST? That's happening for this case, which was added to the classic codegen version of the assign-operator.cpp test when the Sema code to generate the memcpy call was added:

https://godbolt.org/z/xMYPevMMf

There's a comment (which predates the change where this test was added) saying "This optimization only applies for arrays of scalars, and for arrays of class type where the selected copy/move-assignment operator is trivial." So I guess the presence of `B b[16]` in the test is what triggers it. I can see why `memcpy` is used there.

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