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

[Jan Hubicka]

> On Fri, 2003-11-14 at 09:03, Andrew MacLeod wrote:
> 
> > I simply dont see a significant win for this kind of representation. I
> > can't beleive that changing GOTO's and labels are that much of a
> > headache when you want to change program flow. That seems like fairly
> > minor work.
> > 
> Agreed.  All we have to do is hide the goto/label creation inside a
> properly defined API.  What is needed here besides redirect_edge()
> and/or move_block()?

redirect_edge_edge_and_branch is actually the problem.
Any simple optimization pass that operates on CFG and wants edge
redirection must do:
1) check whether edge is abnormal
   if it is, give up
2) check whether edge is fallthru
   if it is, make it nonfallthru
3) check whether 2) introduced new block
   if it happent, update datastructures noticing the new block
4) redirect now non-fallthru edges.

Headache brought by 2) and 3) (where 3) is often not trivial) is the
reason why cfglayout mode has been invented on RTL.

For RTL we dohave redirect_edge_and_branch that does not know how to
deal with fallthru so it returns false, we do have
force_nonfallthru_and_redirect as an helper for 3), and we do have
redirect_edge_and_branch_force that combines these two and we do have
cfglayout mode that solves this in easier way.

For instance duplicating loop body is pain on normal RTL.  While
designing the CFG API I am trying too keep the fact that after each
atomic operation both CFG and RTL match each other.  So if I create
duplicate_block as atomic function, it would be forced to create
fallthru forwarder block when block has fallthru edge.  Now you want to
implement loop body duplication and you end up with creating many
unnecesary fallthru forwarders, having deal with them and not getting
confused and having to cleanup the CFG once you are done.

The situation on RTL where we do have two representations is bad, that
is why we are shooting for makeing cfglayout mode the default and lower
it just shortly before final assembly is produced.

Now we do have trees and we do have same problem (check for instance
implementation of split_edge when there is preceeding block that has
exception edge and fallthru edge).  It would make sense to keep these
two sollutions consistent.

Honza
> 
> I have seen no proof that this new representation can do something that
> cannot be handled by the existing one.  Let's not fix unbroken wheels.
> 
> 
> Diego.
>