[cfe-dev] Adding a CFG node for the allocation call in a new-expression

Anna Zaks ganna at apple.com
Fri Apr 6 13:42:14 PDT 2012

On Apr 6, 2012, at 11:31 AM, Jordan Rose wrote:
>>> Now that the CFG is linearized, it's hard to know what that means. For a normal call, the arguments are evaluated before the PreStmt<CallExpr> callback, then the call itself is inlined or modelled, then there's the PostStmt<CallExpr> callback. For a CXXNewExpr, though, the CFG looks like this:
>>> 1. Evaluate all placement args.
>>> 2. CFGAllocation ***
>>> 3. Evaluate all constructor args.
>>> 4. Evaluate the constructor.
>>> 5. Evaluate the CXXNewExpr.
>>> It's impractical to put the PreStmt<CXXNewExpr> call before all of that, because that removes the whole effort of a linearized CFG. The constructor args really might not be evaluated until after the allocation, according to the standard, but moving them is impractical since there /is/ a CXXConstructExpr (or similar) inside the CXXNewExpr, and the CFG treats that like any other expression. IIRC, we don't have any other Pre/Post pairs that stretch across multiple CFG nodes.
>> If I understand correctly, we want to evaluate the arguments of the constructor before PreStmt<CallExpr>, but it is difficult to do because their evaluation is a part of evaluating CXXConstructExpr, which occurs after CFGAllocation in the CFG. But the following order would be best but difficult to implement. The standard allows evaluation of constructor args before allocation, correct? And the allocation is a part of CXXNewExpr as far as AST is concerned?
>> (just trying to understand the issue..)
>> 1. Evaluate all placement args.
>> 2. Evaluate all constructor args.
>> 4. Evaluate PreStmt<CXXNewExpr>

      4.    Evaluate CFGAllocation
>> 4. Evaluate PreStmt< CXXConstructExpr >
>> 5. Evaluate the constructor.
>> 6. Evaluate rest of CXXNewExpr.
>> ...
> The allocation is just the CXXNewExpr in the AST, but the reason the allocation ought to happen /before/ the constructor is so that the constructor can initialize the right region. Right now that doesn't matter since we're just conjuring a symbol, but if we even get to modelling placement new, let alone handling arbitrary allocators or a new region type like Tom mentioned, we're going to need to do better.

I've just realized that I omitted the allocation from the sequence. I think it might be best if we process PreStmt<CXXNewExpr> before evaluating the constructor AND CFGAllocation. This might not be trivial to implement, but seems to be the right thing to do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120406/20d918e6/attachment.html>

More information about the cfe-dev mailing list