This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
On Fri, 2003-11-14 at 17:14, Jan Hubicka wrote:
> > > > The idea of a TRAP_EXPR which indicates that TREE_OPERAND(trap, 0) may
> > 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.
well, if we had a TRAP_EXPR with a 'GOTO fallthru' and 'GOTO exception'
hanging off it, (like a COND_EXPR node with THEN and ELSE). That was my
thinking. Then if you discover it always traps or never traps, you can
delete the appropriate goto or remove the TRAP_EXPR. And that would
provide you with a GOTO for the abnormal edges too.
> 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.
It does have the advantage of not requiring block splitting and such to
have to do anything special, like looking for shadow gotos. They could
also be expanded/recreated arbitrarily as required.