This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
On Thu, 2003-11-13 at 19:37, Zdenek Dvorak wrote:
> > Doesn't this mean that the IL no longer represents the program by
> > itself? This would require that the CFG be present in order to correctly
> > process the program. I'm not convinced that this is such a good thing.
> when you have cfg, gotos are obviously redundant. The only reason for
> having them would be if they made something simpler, but they do not;
> they in fact complicate every cfg manipulation.
You could argue with GOTO's the CFG is obviously redundant. the CFG is
an abstraction of the flow of the program, it isn't the actual flow. the
GOTOs are the flow. Thats why you have to put them back in when you
destory the CFG.
As Chris says, you consult the CFG to manipulate the IL...
> > I
> > understand there are benefits, but there are also negatives. Thats a big
> > enough switch that we're almost handling 2 ILs in my books.
> Could you be more specific about the negatives? I fail to see any.
I can think of a few right off the top of my head.
- Any simple optimization which doesn't require the CFG will no longer
function on the program,
- Any such optimization requires 2 versions now, so that implies you
have two ILs. I personally dont want to support different versions of
the IL for little reason. Thats a drawback. Any generic routines you
call into that examines the IL have to be aware of 2 possible ILs.
There are times when we might want to combine/regimplify one or more
stmt's. This will clearly fail if it includes any of CFG IL modified
stmts without teaching gimplification about the CFG.
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