This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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