Represent all assignment operator calls in the IR

[smeenai]

ClangIR tries to represent all function calls in the IR (e.g. CodeGen omits calls to trivial constructors but CIRGen keeps them). One exception I've discovered is around calling operator= for an array member when generating a default operator=. https://godbolt.org/z/nEE46ff9d is an example; for the following code:

struct S { int i; };
struct T {
    S arr[4];
    T &operator=(const T &);
};
T &T::operator=(const T &) = default;

The generated code for T::operator= does a memcpy for the arr field instead of emitting the individual S::operator= calls for each array member.

This stems from how CIRGen (and CodeGen) generate default assignment operators. Clang generates an AST representation of the assignment operator, which already contains a __builtin_memcpy call for the arr field, and then CIRGen emits code for that AST. We'd need to change the AST itself to not generate a memcpy here.

[bcardosolopes]

We'd need to change the AST itself to not generate a memcpy here.

Not necessarily, we could look at the node children to realize a __builtin_memcpy is there (a small hand written visitor could be necessary) and just bypass it because the new CIR operation emitted would imply such memcpy during lowering.

EDIT: Maybe changing the AST could be the long term solution, my point is that it shouldn't block us to make this happen since it's fairly orthogonal

[smeenai]

The visitor already exists here. The problem is that the AST doesn't distinguish between arrays of primitive types (which we'd still want to memcpy) and arrays of trivial structs: https://godbolt.org/z/xcMbd8qPT. We can examine the field type in that visitor, but if the visitor says the field isn't memcpyable we'll fall back to CGF.emitStmt, which will translate that AST node into a memcpy anyway. We can special case that again, but it seems kinda ugly vs. changing the AST.

https://godbolt.org/z/fhbM8ajja is an example with a non-trivial assignment operator for reference, and the generated AST contains a full initialization loop. I'm also including the default copy constructor for reference, and it's interesting that it has a much higher-level representation (ArrayInitLoopExpr, which #1055 discusses the appropriate CIR equivalent for). I imagine we'll also want to raise assignment operator loops in the future.

[bcardosolopes]

I think it's totally reasonable if high level code for this is just a thin wrapper for starters (e.g. a new operation with all this logic happen within it's region), this way we don't have to deviate from CIRGen, and will delimit initialization code altogether, such that when we get fancy with analysis we can then play more with additional abstractions.