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 17:33, Jan Hubicka wrote:
> > On Thu, 2003-11-27 at 16:34, Jan Hubicka wrote:

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

If they are identical, why do we need to go to the effort of changing
the the IL to remove GOTOs and replace them all with CFG edges.  I
thought that was primarily to make dealing with forwarder blocks easier?

I am not suggesting that the commit routine be called at the end of ssa,
Im suggesting it be called whenever it can be, just like
bsi_comit_edge_inserts()... As sonn as the new BBs are not going to be
an issue, you create them.


> 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


I think mine is a lot less intrusive than removing all the GOTOs , using
CFG edges everywhere, and then rewriting all the GOTO's and labels when
done.  

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

I dont see how its any different than what we do with stmt's inserted on
edges. Its only a temporary thing until the side effects are no longer
an issue, then you commmit them. You should never have to deal with
things waiting for a commit, and they certainly ought to be commited
before you verify flow information. I would expect it to be an error if
there are pending forwarder actions at that point... The effects of the
delayed commit are completely transparent until you want the new blocks
to be created.. are they not? All it does is possibly add zero or more
GOTOs and create new basic blocks.

Maybe we need to clarify what we are discussing again :-)


Are we simply talking about removing all the GOTO_EXPR's in the program
now, and letting the CFG edges represent those GOTO's? . Is there
anything *other* than explicit GOTOs which are involved? And the reason
this is better is because we dont have to deal with GOTOs that are
required in new basic blocks caused by forwarder blocks which get
created when GOTOs are required?



Andrew


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