[cfe-dev] Representing the allocation in CXXNewExpr

[John McCall]

On Mar 30, 2012, at 2:34 PM, Jordan Rose wrote:
> - Itanium name-mangling, which currently skips the size argument. The Itanium spec does seem to imply that this is correct (the size is skipped for the expression but not for the allocator function's name), but there's no clause dealing specifically with new and new[].

This is actually a bug, since the size operand of a new[] could be instantiation-dependent and therefore affect overload resolution.  I'll raise that with the ABI list.

> - TreeTransform, which currently rebuilds the new expression /and/ the allocation call from scratch (because the two aren't distinct in Sema). This probably wouldn't be /too/ hard to change; I just haven't done it yet.
> - CodeGen: Delete cleanups if the allocator fails. We're already keeping all the placement args around, though...no reason not to just extract the size argument from there too.
> - CodeGen: We need to know the array+cookie size for the call to the allocator and the array size alone for the call to the initializer.
> 
> That last one is the killer. Teaching CXXOperatorCallExpr to just skip its first argument for printing and mangling wouldn't be so bad, but I'm not so happy about computing the array size again for the initializer call. And if we extract it from the arguments list, we just have to subtract the cookie size off again.

And the fact that IR-gen has to give special treatment to the fact that the computation can overflow.  I assume that's been covered elsewhere here.

> I do want to point out a couple good things I /hadn't/ put in the first version that this would allow -- namely, killing an old FIXME about using CheckFunctionCall, which we can actually do now. (Though right now CheckFunctionCall skips C++ operators, even though there could easily be nonnull/format attributes attached for the placement args.) If we can solve the CodeGen problem, then we also get to re-use all the real argument emission code for that too. (Of course, we could do that anyway by adding a flag to EmitCallArgs.)

To be perfectly honest, it sounds like this proposal is just complicating the representation of CXXNewExpr without significantly reducing the amount of special-case work that needs to be done in the clients.

John.