Re: [tree-ssa] Removal of gotos from cfg based ir

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2003-11-14 at 15:25, Chris Lattner wrote:
> On Fri, 14 Nov 2003 law@redhat.com wrote:
> 
> > In message <Pine.LNX.4.44.0311140104370.31354-100000@nondot.org>, Chris Lattner
> >  writes:
> >  >> > how do you get the edges in the cfg then?
> >  >> Def-use edges, which are tracked for all SSA values.
> >  >Sorry for the terseness.  Def-use edges are used to get predecessors,
> >  >use-def edges are used to get successors.
> 
> > Sorry if I'm being overly dense -- I don't see how def-use or use-def
> > gets you control edges.  Unless you do something like build the SSA
> > graph for jump targets/jump statements.  Is that what LLVM does
> > (if so, I'll have to sit down and think about that for a while, it's
> > an interesting idea... )
> 
> Oh right, sorry.  In LLVM, each function contains a doubly linked list of
> basic blocks.  Each basic block contains a doubly linked list of
> instructions (thus the CFG contains the instructions themselves).  To get
> the predecessors of a block, you simply look at all of the users of that
> block (which are the control flow instructions at the end of predecessor
> blocks).  To the successors of a block, we just look at which basic blocks
> the terminator at the end of the block branches to.
> 
> So, in other words, each basic block has a use list, and all terminator
> instructions (e.g. branches) _use_ the basic block destinations.  With
> this organization, the SSA graph provides the CFG, and it can never get
> out of date.

So basically you reduce the CFG to a use-def chain of flow-affecting
stmts the same way SSA reduces the information for data-affecting stmts.
The CFG is flow-ssa, and the data part is what we usually refer to as
SSA form, or data-ssa for you :-)

Is that right? 

Andrew