adams381 wrote:
The current change mirrors classic CodeGen rather than diverging from it.
`CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr` takes the same trivial
copy/move-assignment path: it evaluates the RHS lvalue and calls
`EmitAggregateAssign` at the call site, and never emits a call to the trivial
`operator=`. This PR does exactly that.
The empty body isn't something this PR introduces — classic emits the same
thing. Forcing classic to emit the union's `operator=` body (e.g. by taking
`&U::operator=`) gives, at `-O0 -emit-llvm`:
```llvm
define linkonce_odr ptr @_ZN1UaSERKS_(ptr %this, ptr %0) {
entry:
%this.addr = alloca ptr
%.addr = alloca ptr
store ptr %this, ptr %this.addr
store ptr %0, ptr %.addr
%this1 = load ptr, ptr %this.addr
ret ptr %this1
}
```
No memcpy — classic's trivial union `operator=` body never performs the copy.
That's harmless precisely because the call-site shortcut means the body is
never what does the assignment. So making the body copy would be a departure
from classic, not a correction toward it, and the `-O3` store-deletion this PR
fixes comes from the call-site path, not the body.
If we instead want CIR to keep the `operator=` call so the CIR optimizer can
reason about it, backed by a body that actually copies, that's a deliberate
improvement over classic and I'm happy to take that direction. It's a separate
goal from matching classic and fixing the regression, which is what this PR
currently does.
https://github.com/llvm/llvm-project/pull/198918
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
