[cfe-dev] CFG: scopes and destructors

[Marcin Świderski]

Hi Zhongxing,

W dniu 11 sierpnia 2010 04:58 użytkownik Zhongxing Xu <xuzhongxing at gmail.com
> napisał:

Hi Marcin,
>
> It is not clear where the CFGScope will fit in the original
> CFG-CFGBlock-CFGElement hierarchy. It looks like CFGScope is
> equivalent to the CFGBlock. Can we just extend CFGBlock? Whenever a
> new scope begins, we create a new CFGBlock for it. We add a 'Parent'
> member to CFGBlock and let it point to the parent block and the
> position where the scope begins.


Yes, I think it could be done. Because scope can have many CFGBlocks
in it we could use the 'Parent' member to:
  - point to enclosing scope in CFGBlock that begins a scope,
  - point to previous CFGBlock in the same scope for other CFGBlocks.
  - point to nothing if the CFGBlock is not relevant for the scope (has
    no declarations)
This way it would be easier to traverse through CFGBlocks in search
of declarations. The downside would be that we would have more blocks
in CFG then it would be needed.



Currently we don't distinguish Decls and Stmts in the CFGBlock (Decls
> are DeclStmts), because Decls may have Stmts as their initializers and
> we need to visit them along with other Stmts. But it is desired to
> improve this representation.
>

If we go through statements in a block we can spot declarations by type.
Do we need more information than that?

>
> Destructors could be implicit in the CFG. The client can maintain a
> list of Decls which need to be destructed. An explicit list of Decls
> in each scope-beginning CFGBlock may help in this case.
>

CFGScope is in large part just that: an explicit list of declarations.

>

2010/8/10 Marcin Świderski <marcin.sfider at gmail.com>:
> > Hi,
> > I'm trying to figure out how to add scopes and destructors to CFG. As I
> > understand, what we need is:
> > For scopes:
> > - CFGElement kinds for start/end of scopes that would allow for tracking
> > entering and leaving scopes.
> > - If there are no variable declarations in scope, scope start/end
> elements
> > should be omited.
> > - Scope end element should be omited if there are no variable
> declarations
> > before it in the scope.
> > For destructors:
> > - CFGElement kind for call to destructor.
> > The main problem with implementing this in CFGBuilder is that the builder
> is
> > processing AST backwards. When the builder have to decide if it should
> add a
> > scope end element or a destructor it doesn't know of variables declared
> > earlier in the scope. To solve this there have to be an additional step
> of
> > walking e.g. a block of statements (compound statement) and creating a
> list
> > of all statements declaring variables.
> > Solution that I would like to propose is to make those lists a part of
> CFG
> > instead of just temporary data used while building the graph. It would
> look
> > something like this:
> > class CFGScope {
> >   Stmt* stmt; // Statement that creates the scope (e.g. CompoundStmt)
> >   vector<Stmt*> decls; // Statements that declare variables in same order
> as
> > in AST
> >   CFGScopeIterator parent; // Link to position in parent scope where this
> > scope started
> > };
> > class CFGScopeIterator {
> >   CFGScope* scope; // Scope pointed by iterator
> >   vector<Stmt*>::iterator pos; // Position in declarations list of the
> > scope.
> > };
> > Now the scope start element would point to CFGScope object. The scope end
> > element would point to pair (range) of CFGScopeIterators: first would
> point
> > to position in current scope the scope end occured, second would point to
> > position in some scope where the control flow did jump to. Element for
> > destructors wouldn't be needed, because destructors could be easly
> deduced
> > from range in scope end element.
> > This design would allow for simple implementation of jumps out of nested
> > scopes and simple modeling of destructors. Similar design could be used
> to
> > model destructors for temporary objects.
> > What do you think about this design?
> > Cheers
> > Sfider
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100811/d58540d3/attachment.html>