This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

> 
> 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.

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
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.


> Concerning the argument about saving IL into file, we can either save
> the Il before lowering it for optimization or save the CFG as well - it
> is not too much pain.
> 
> Concerning the argument that function lowering would not be needed, I
> think it is wrong.  If we manipulate the CFG in arbitrary way, unroll
> loops and such, we would not be able to match it back into original
> control flow statements.

I agree, lowering was necessary. It wasn't much of an argument :-)

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]