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

[Jan Hubicka]

> 
> > > I do believe that approach of making CFG part of the IL (not making IL
> > > uncomplette) is the most consistent sollution and probably easiest to
> > > deal with. My next candidate would be the idea of shadow gotos, but I
> > > would preffer to avoid it.
> 
> > IF you are entering a part of the optimizer where you are going to do
> > this kind of manipulation a lot,  why not simply change all FALLTHRU
> > edges in the program to be explicit GOTOs until such time that you no
> > longer need it?  Is this what LLVM does? Its seems like the most natural
> > way of dealing with the problem if its that sticky of an issue. then
> > presumably cfg_cleanup will get rid of them all when you are done, if
> > the blocks are indeed still consecutive.
> 
> In LLVM, all control flow (for both normal and exceptional control) is
> represented explicitly in the program.  For example, "fall-through" edges
> are explicit gotos, which are eliminated during code generation.  This
Interesting.  How do you deal with the exception handling edges?
Does call having EH edge become somthing like call+goto combo?

Honza
> means that a code layout pass only needs to reorder blocks, it does not
> need to modify the CFG or instructions _at all_.
> 
> An easy way to see what LLVM does to various programs is to try out the
> online web form:
> http://llvm.cs.uiuc.edu/demo/
> 
> Which will print out the LLVM code for any C or C++ translation unit you
> give it.
> 
> -Chris
> 
> -- 
> http://llvm.cs.uiuc.edu/
> http://www.nondot.org/~sabre/Projects/
>