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

[Jan Hubicka <jh at suse dot cz>]

> On Thu, 2003-11-13 at 19:37, Zdenek Dvorak wrote:
> > Hello,
> 
> > > 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, 

Can you give me example?
Simple optimizations not requiring CFG are usually local optimizations.
These could be written as 
FOR_EACH_BB ()
  do local work.
> - Any such optimization requires 2 versions now, so that implies you
> have two ILs. I personally dont want to support different versions of

Why would you need 2 versions?  The idea is that we will always operate
on form with the CFG built.

I do have the RTL expansion pass that use CFG (to preserve profile
mainly).  In longer run, I would like to enter RTL already in cfglayout
mode, so we avoid need to invent/kill the gotos on the way.

Honza
> 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
> minor work.
> 
> Andrew
> 
> 
> 
>