<div class="gmail_quote">Hi Zhongxing,</div><div class="gmail_quote"><br><div class="gmail_quote">W dniu 11 sierpnia 2010 04:58 użytkownik Zhongxing Xu <span dir="ltr"><<a href="mailto:xuzhongxing@gmail.com" target="_blank">xuzhongxing@gmail.com</a>></span> napisał:<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marcin,<br>
<br>
It is not clear where the CFGScope will fit in the original<br>
CFG-CFGBlock-CFGElement hierarchy. It looks like CFGScope is<br>
equivalent to the CFGBlock. Can we just extend CFGBlock? Whenever a<br>
new scope begins, we create a new CFGBlock for it. We add a 'Parent'<br>
member to CFGBlock and let it point to the parent block and the<br>
position where the scope begins.</blockquote><div> </div></div><div>Yes, I think it could be done. Because scope can have many CFGBlocks</div><div>in it we could use the 'Parent' member to:</div><div> - point to enclosing scope in CFGBlock that begins a scope,</div>
<div> - point to previous CFGBlock in the same scope for other CFGBlocks.</div><div> - point to nothing if the CFGBlock is not relevant for the scope (has</div><div> no declarations)</div><div>This way it would be easier to traverse through CFGBlocks in search</div>
<div>of declarations. The downside would be that we would have more blocks</div><div>in CFG then it would be needed.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently we don't distinguish Decls and Stmts in the CFGBlock (Decls<br>
are DeclStmts), because Decls may have Stmts as their initializers and<br>
we need to visit them along with other Stmts. But it is desired to<br>
improve this representation.<br></blockquote><div><br></div></div><div>If we go through statements in a block we can spot declarations by type.</div><div>Do we need more information than that?</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Destructors could be implicit in the CFG. The client can maintain a<br>
list of Decls which need to be destructed. An explicit list of Decls<br>
in each scope-beginning CFGBlock may help in this case.<br></blockquote><div><br></div></div><div>CFGScope is in large part just that: an explicit list of declarations. </div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2010/8/10 Marcin Świderski <<a href="mailto:marcin.sfider@gmail.com" target="_blank">marcin.sfider@gmail.com</a>>:<br>
<div><div></div><div>> Hi,<br>
> I'm trying to figure out how to add scopes and destructors to CFG. As I<br>
> understand, what we need is:<br>
> For scopes:<br>
> - CFGElement kinds for start/end of scopes that would allow for tracking<br>
> entering and leaving scopes.<br>
> - If there are no variable declarations in scope, scope start/end elements<br>
> should be omited.<br>
> - Scope end element should be omited if there are no variable declarations<br>
> before it in the scope.<br>
> For destructors:<br>
> - CFGElement kind for call to destructor.<br>
> The main problem with implementing this in CFGBuilder is that the builder is<br>
> processing AST backwards. When the builder have to decide if it should add a<br>
> scope end element or a destructor it doesn't know of variables declared<br>
> earlier in the scope. To solve this there have to be an additional step of<br>
> walking e.g. a block of statements (compound statement) and creating a list<br>
> of all statements declaring variables.<br>
> Solution that I would like to propose is to make those lists a part of CFG<br>
> instead of just temporary data used while building the graph. It would look<br>
> something like this:<br>
> class CFGScope {<br>
> Stmt* stmt; // Statement that creates the scope (e.g. CompoundStmt)<br>
> vector<Stmt*> decls; // Statements that declare variables in same order as<br>
> in AST<br>
> CFGScopeIterator parent; // Link to position in parent scope where this<br>
> scope started<br>
> };<br>
> class CFGScopeIterator {<br>
> CFGScope* scope; // Scope pointed by iterator<br>
> vector<Stmt*>::iterator pos; // Position in declarations list of the<br>
> scope.<br>
> };<br>
> Now the scope start element would point to CFGScope object. The scope end<br>
> element would point to pair (range) of CFGScopeIterators: first would point<br>
> to position in current scope the scope end occured, second would point to<br>
> position in some scope where the control flow did jump to. Element for<br>
> destructors wouldn't be needed, because destructors could be easly deduced<br>
> from range in scope end element.<br>
> This design would allow for simple implementation of jumps out of nested<br>
> scopes and simple modeling of destructors. Similar design could be used to<br>
> model destructors for temporary objects.<br>
> What do you think about this design?<br>
> Cheers<br>
> Sfider<br>
</div></div><div><div></div><div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
</div></div></blockquote></div></div></div><br>
</div><br>