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

[Jan Hubicka <hubicka at ucw dot cz>]

> > Also I would like to point out that the scheme is used in some other
> > compilers.  It is also similar to one used by Morgan's book that also do
> > combine CFG construction and intermediate code production
> 
> 
> I, for one, never trust anything I read :-) They always expound the
> virtues, and its an exercise left to the reader to discover the horrible
> reality of making the author's choices. :-)
True :)
I just noticed it last week while looking into that book.  We got into
the indea independnetly earlier while working on RTL.
> 
> Why should the program be represented differently during all these
> phases when we the representation we have works? We dont want a
> different IL during inlining or expansion in my opinion. 

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.
> > It is not only about replication.
> > For example if you want to take advantage for this during cfgcleanup,
> > you will have to enter the block_replication mode very often, kill all
> > gotos and forwarder blocks and re-emit them during leaving.  This is
> > expensive.
> 
> 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.

The problem of RTL part of optimizer is that right now not all passes
are updated to use CFG and some still do look into branch instructions
and thus we need to massage things back and forth thus we need some kind
of bookeeping.

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. 

Honza