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

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2003-11-27 at 16:34, Jan Hubicka wrote:

> I would say that these all can use CFG representation as it is good for
> all of these passes, but we can deal with this one by one and decide
> what is best separately.
> I didn't seen any reason why CFG represenation is bad for inlining or
> mudflap.
> For inlining we will need some extra work to allow multiple CFGs at
> once, but it is consistent with my longer term plan for profile
> information.

If someone wants to write an optimization that manipulates the IL and
doesn't want or need a CFg for their owns reasons, we ought not be
forcing them to work with one. 

> > 
> > No, Im not suggesting we "enter" block replication mode. There is no
> > translation in and out of unaffected regions.
> > 
> > What I am suggesting is that if you want to replicate a block, you call
> > a routine, "replicate_block(bb)" which performs your block replication,
> > creates your new BB, creates appropriate edges, and enters this new BB
> > into a list.
> > 
> > Then when you are ready to handle any new basic blocks that might be
> > required, you call "commit_block_replications()" which goes through the
> > list of new blocks that have been created, checks each one to see if it
> > has caused a successor with more than one predecessor which is a
> > fallthu, and if so, adds the required new BB, GOTOs and labels to make
> > the trees correct, all at once.
> 
> What would you buy by calling commit_block_replications before you are
> done with SSA optimization queue?  If you call it exactly once when you
> are done, you get identical sollution to what Zdenek did, just do use
> different names.
> 

Its the same reason we dont call commit_edge_insertions() at the end of
the SSA pass. As sson as the nbew block which might need to be created
are not going to be a problem, we call the routine so that everything is
in sync.

Your problem is that when you are in the middle of doing thing, new
basic blocks are appearing. So you can add your basic blocks, do your
work, and as soon as the newly appearing basic blocks aren't going to
affect what you are doing,  you call commit() to create the new blocks
required.

> Really I don't think there are much alternatives.  If you start by any
> idea I can come with (shadow block, cfglayout mode allowing temporary
> redirections, commit_edge_redirections) and you start doing conservative
> improvements, you end up with Zdenek's sollution. 

I dont see how this makes anything conservative... 

Lets try something more concrete. Give me an exmaple of where you do
something which is going to cause a forwarder block, but where doing the
"commit" or "new block creation" when the new block(s) isnt going to
cause a problem is not going to work, or cause you to be more
conservative, and we'll go from there.
Andrew