[cfe-dev] CFG: scopes and destructors

[章磊]

2010/8/11 Ted Kremenek <kremenek at apple.com>

> Hi Marcin,
>
> First, I want to thank you for working on this.  Adding support for
> destructors, and possibly scopes, to the CFG is something that is sorely
> needed for analyzing C++ code.
>
> At the risk of sounding pedantic, I think when evaluating our possible
> approaches it's really important to keep in mind both *how* the information
> in the CFG will be used to service clients and *what* information the CFG is
> meant to represent.  Second, I think we shouldn't focus on the
> implementation details (e.g., "the builder is processing AST backwards") of
> how we would construct the information before we have an idea of what the
> right API is for accessing the information in its final form.  The whole
> point of the CFG is to make it easier to write analyses, so having a good
> API that represents useful information is the primary goal.
>
> That's all well and good, but what does that mean?  First let's step back
> and examine what purpose the CFG serves.  The CFG is meant to represent
> control-flow in a function; nothing more and nothing less.  Representing the
> control-flow is important for any analyses we want to build on top of the
> CFG that want to know the ordering between statements, the change of control
> caused by jumps and loops, etc.  With this in mind, let's consider both the
> problem of scopes and destructors.
>
> From your proposal of CFGScope, if you take a look at the definition it
> actually has nothing to do with control-flow at all.  In C and its
> derivatives, scope is purely a lexical concept.  This is evident since Sema
> and the Parser reason about scopes but don't actually reason about
> control-flow.  If you renamed 'CFGScope' to 'ASTScope' then it functionally
> would be the same thing.  Thus in my mind tying it to CFGs really has no
> value, and conflates our mental model of what the CFG does.  I think it's
> reasonable to consider building ASTScopes (or whatever they are called) as
> part of the process of building a CFG (sort of a by-product), but unless the
> scope information is valuable to model in the CFG as something a client of
> the CFG would want to know about *when reasoning about control-flow* then I
> think it is an orthogonal topic.  Before I believe I argued that this
> information could be represented in the CFG, but I'm honestly not certain
> what benefit that would provide other than modeling when we cross scope
> boundaries.  That information, however, can likely be constructed by
> analysis using a side map from statements to scope, so it's not clear if
> that needs to be in the CFG.
>

It seems that gcc's gimple cfg has the same idea.

int main() {
  int x;
  {
    int y;
    {
      int z;
    }
  }
}

gcc's tree cfg :

;; Function main (main)

Scope blocks:

{ Scope block #0
  int x; (unused)

  { Scope block #0
    int y; (unused)

    { Scope block #0
      int z; (unused)

    }

  }

}

main ()
{
  int z;
  int y;
  int x;

<bb 2>:
  return;

}





-- 
Best regards!

Lei Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100811/d2af5483/attachment.html>