[cfe-dev] CFG blocks and variable scope

[Ted Kremenek]

On Mar 31, 2009, at 1:09 AM, Martin Doucha wrote:

>> This aside, we certainly can handle the case you described with the
>> right abstractions and still provide the same CFG interface that
>> clients expect.  Since we are free to implement basic blocks in any
>> matter that we wish (and have different kinds of basic block
>> encodings), we can use virtual basic blocks to encode what variables
>> are destroyed but employ data sharing between these virtual basic
>> blocks to keep the memory costs down.  Through a proper iterator
>> interface, clients would iterate over the "virtual" statements in the
>> virtual basic blocks, even if we don't explicitly create those
>> statements.  This approach can be viewed of the combination of the  
>> two
>> approaches discussed, except that this has a simpler interface for
>> clients.
>
> Excellent. Let's get coding. Where do I start implementing this  
> design?


Hi Martin,

I think for starters there are two things:

(1) Where do we get the scope information that we need?

(2) What should be the interface for clients?

Ideally (1) comes from Sema.  I don't want us to reconstruct scope.   
We should solicit comments from others on cfe-dev on the best way to  
query scope information (those working on the C++ side of things might  
have some specific thoughts).

For (2), we need to think of how to deliver this information to  
existing clients.  Do we introduce a new subclass of Stmt that is  
publicly visible in the ASTs (I don't think this is a great idea) or  
do we have CFGBlocks contain smart pointers that reference either  
Stmt* (the case right now) or Decl* (which would represent a variable  
going out of scope).  If we choose the latter, we need to update the  
client interface for CFGs (and the clients themselves) before we start  
making changes to CFG construction.  That way once we have CFGs that  
contain the "object is now dead" information our clients will be able  
to pick it up.

Also, I think the compact representation in the CFG that we discussed  
should come last.  I see it as an optimization.  Once all the  
interfaces are in place we should be able to switch over to it.  Doing  
it first would introduce one more implementation detail that would get  
in the way of having an end-to-end implementation.

What do you think?