[cfe-commits] [Review] Partial fix for PR 11645: put destructor calls before a return statement.

[Chandler Carruth]

On Tue, Jan 17, 2012 at 8:37 AM, Ted Kremenek <kremenek at apple.com> wrote:

> If you would want to base code generation on the CFG, it
> would force an extra pass to identify whether calculated values should
> be constructed in a return value slot or not. So I think that using
> return/throw (and possibly goto) as markers, would be a simplification.
>
> Concerning "goto" and "throw"; those are terminators and already can serve
> as markers.  I'll elaborate with the case of "return".  I'm also not
> certain what you mean by an "extra pass", but it *might* require some work.
>
> My concern is that, unlike "goto", the "return" in the CFG is not a
> terminator; it doesn't represent a transfer of control.  That's what
> terminators in CFGBlocks are for.  Instead, it appears in the CFGBlock as
> an element, which means (in that context) it represents a statement that
> gets executed.  Since it doesn't represent the transfer of control in that
> context, the sole role of the "return" in the CFG is to represent the
> binding of the return value.
>
> That said, we could place the "return" as a terminator, in *addition* to
> what we do now, and have that terminator terminate the CFGBlock with the
> destructor calls in it. That terminator would be on a CFGBlock that
> transitioned to the Exit block.  Doing this isn't absolutely necessary, but
> it would annotate the end of the CFGBlock with the return statement,
> possibly making it more amendable to code generation while still preserving
> the invariants of the CFG.
>

I really like this model. I think viewing 'return' as a terminator which
transfers control (perhaps indirectly, see below) to the exit block fits
the CFG model and the standard model very well.

Also, I would further separate the invocation of block-scope variable
destructors into a CFGBlock between the return statement an the exit block.

Essentially, I feel there are two buckets of destructors relevant to a
return: those destructors which are invoked as part of the full-expression
on the return statement, and those which are invoked as each block scope is
exited. The former seem to belong inside the same CFGBlock as the return
statement as they can only be reached by reaching that particular
statement. The latter, however, should be shared between all of the return
statements which have the same stack of variables to destroy.

I've not tested this thoroughly recently to see how this is currently
modeled, we may already be very close to this model...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120117/5d76413f/attachment.html>