<div class="gmail_quote">On Tue, Jan 17, 2012 at 8:37 AM, Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div> If you would want to base code generation on the CFG, it </div><div>
would force an extra pass to identify whether calculated values should </div><div>be constructed in a return value slot or not. So I think that using </div><div>return/throw (and possibly goto) as markers, would be a simplification.</div>
</div></div></span></blockquote></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</blockquote></div><br><div>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.</div>
<div><br></div><div>Also, I would further separate the invocation of block-scope variable destructors into a CFGBlock between the return statement an the exit block.</div><div><br></div><div>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.</div>
<div><br></div><div>I've not tested this thoroughly recently to see how this is currently modeled, we may already be very close to this model...</div>