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

[Jan Hubicka <jh at suse dot cz>]

> On Fri, 2003-11-14 at 16:28, Jan Hubicka wrote:
> > > 
> > > I dont see that its helps that much. There is a small amount of bookwork
> > > required to maintain the stmt's in step with the CFG, but it certainly
> > > doesn't seem to be very much,as long as the flow is explicit in the IL
> > > (or insn stream if you prefer). 
> > 
> > On RTL, cfglayout is about 1300 lines and good about half of cfgcleanup
> > is about bookkeeping the forwarders and geting across them.  Plus we do
> > have code in other places that use redirect_edge_and_branch_force.  I
> > think this is actually quite a lot of code and I was doing my best to
> > make it as small as possible. It would be even more in tracer/loop
> > unroller if we didn't use cfglayout.
> > 
> > I think this is quite a lot of complexity.
> 
> If we can expose the flow properly, then we dont have this complexity. I
> was refering to if we can get it exposed properly, which I think we can.

On RTL, we expose the hardware instructions, so there is not much
sollution except for having fallthru edges.  I see that on tree it is
diferent and it is great that we do have two way jumps instead of
conditional jumps.  It already makes tree manipulation much easier.
> 
> > 
> > I don't worry much how we do it (CFG as IL or gotos inside the shadows
> > or so), but I definitly want to see fallthru edge gone or arbitrarily
> > redirectable.  
> > Do we know of other alternatives?
> > What would be the preference?
> > I would like to avoid the idea of containers representing EH edges as it
> > complicates simple analyzers of instructions.
> > 
> 
> No more so than a cast complicates analyzing the RHS of an expression?
> Perhaps a bit more since its the root expression.

I think Jeff invented the unseless_conversion because the casts has been
anoying.
Think of common usage of this infromation.  It seems to me that there
are global passes that does not worry about semantics and look at the
CFG only.  These does not benefit from TRAP_EXPR at all as long as we
maintain explicit CFG datastructure.
The typical local optimizer does not worry about the trappingness at
all; just looks on the semantics and when it sees the basic block is
over it just moves to new basic block.
In fact I can not think of single code on RTL that does use both
information at once.

One thing that may make this usefull is the need to elliminate EH edge
when the trapping part of instruction has been elliminated.  It is not
clear to me however, how to easilly track whether TRAP_EXPR has been
lost or not.  On RTL we do that via purge_dead_edges that simply check
that the last instruction of basic block still traps.
> 
> 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.
It is similar to idea of notes in RTL, but it has it's own problems.
Idea that any instruction may have hidden GOTO in it does not sound too
nice either.

> understand that then yits more painful to simply look at the stmt when
> you dont care about traps. Perhaps its better as a field in a stmt node.
> If its present, it has the flow labels, and it isn't a hassel for anyone
> then.
> 
> I dont want the cfg manipulations to be awkward, but I dont see why it
> cant also be represented in the IL in some reasonable fashion. I'll
> think about it some more on the weekend.

Honza