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

[Jan Hubicka <hubicka at ucw dot cz>]

> > > The idea of a TRAP_EXPR which indicates that TREE_OPERAND(trap, 0) may
> > > trap, and where it may trap to, seems pretty reasonable to me. I
> > 
> > Implementing this on side as part of statement node would probably work.
> 
> Thats my curent line of thought.
> 
> > It is similar to idea of notes in RTL, but it has it's own problems.
> 
> What kinds of problems would it have. I think its different than a note,
> it an actual part of the stmt since its makes a stmt also contain a
> GOTO, so it can't be ignored if present.
> 
> > Idea that any instruction may have hidden GOTO in it does not sound too
> > nice either.
> > 
> 
> I dont know that I'd call it hidden. This stmt is always going to be the
> last stmt in a block. is is_ctrl_* routines would simply add a check to
> see if the field is not empty.  I think its a lot less hidden than an
> abnormal edge is
The GOTOs are not representing abnormal edges, but the other edge.
We can have another pointer for the abnormal edge destination tought.

It is just hidden in a way that it is not as easy to look for GOTOS
while scaning instruction stream as it used to be.  Still it is not
terribly dificult.

Your idea seems to be very close to concept of the shadow gotos.  Only
pointer in your scheme is placed in each statement node, while with
shadow goto, the goto is nromally in instruction stream just after the
basic block pointed to by pointer from basic block, so it should be less
memory intensive and has advantage of not needing the change in IL.
> 
> I dont know how many places we'd have to change code to deal with a
> cause where you've replicated a block and the fallthrough edge is no
> longer immediately following the stmt. I would like to think that any
> such occurence would immediately abort() in one of our checks somewhere.
> I'd also like to think it would never come up, and just be handled :-)

It should not be terribly dificult in both schemes, as the GOTOs are
simply uninteresting for most of our code that rely on CFG.
> 
> Anyway, I dont profess to know all the answers today, Im making this up
> as I go, maybe triggering a bright idea from someone else.

It is usefull to discuss such decisions :)  You brought up ideas I never
tought about..

Honza
> 
> Andrew