This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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.

No, you are missunderstanding me here.
I am arguing that your sollution + commit_edge_redirections called once
at the end of SSA optimizers queue is identical to Zdenek's sollution.
The only difference is how you call things.

Your's commit_edge_redirections is disband_implicit_edges.
Rest of Zdenek's patch is mostly about removing things that are no
longer needed and reorganizing things so the gotos are alliminated from
CFG early, instaed of after first cfgcleanup pass your sollution would
do.

I believe it is consistent to thing about it Zdenek's way.  One
important invariant is that after each CFG/IL manipulation routine the
CFG is consistent in a way so verify_flow_info passes.  Maintaining this
makes whole CFG interface stateless and much easier to think about and
debug.

With your design we do have two states (either with redirected edges
waiting for commit and without) this only adds little extra complexity.

Honza

Honza
> Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]