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 12:13, Zdenek Dvorak wrote:
> Hello,
> 
> > > > I am not quite sure what was the resolution of the discussion; anyway,
> > > > here is the patch without the {COND,SWITCH}_EXPR ==> CF_EXPR change.
> > > 
> > > My honest belief is that we end up with agreement that declaring CFG as
> > > part of low level trees IL is good idea, so I really hope we will make
> > > progress on this and get into job of doing real cfg_cleanup and CFG
> > > manipulation infrastructure soon.
> > > 
> > To date I have not seen a convincing argument supporting this IL
> > change.
> 
> ummm. I believe Honza has sent a list with a long list of such arguments
> in the thread; I don't want to repeat it here, since it should be easy
> to find.
Then I think a summary is in order since I don't recall seeing a long
list of supporting arguments. I recall 2 things.

> 
> There is of course nothing that would be impossible in the current
> state; this is equivalent change.  Just many things are easier, since
> you have no problems of this type:
> 

I recall these 2, are there more?

1 - copying blocks with fallthrough edges AND abnormal edges causes a
new block to be created. (this was the primary reason I think)
2 - propagating profiling information along the cfg.

If those are the only significant problem (and I dont consider things
like having to add a label or modify a jump to be significant. Magically
appearing BB's *are* a problem) it seems like a lot of impact in order
to make them simpler when we can handle it a different way, and we wont
impact things like mudflap and the inliner, which are pretty unrelated.

Out of curiosity, why can't we deal with 1) by delaying updating the IL
until we're done, like we do with edge insertion.

  BB1
     call X
  BB2			BB9
     <..>		  exception...


duplicate BB1, make the edges the same, a fallthrough edge to BB2, and
an abnormal edge to BB9. 

So we duplicate BB1, producing BB12:
BB1
  call X
BB2                     BB9
  <...>			  exception

BB12
  call X  (BB12--fallthru-> BB2,  BB12--abnorm-> BB(

Then when you are done with the block manipulations, call
commit_block_replications() or somesuch thing, and any block which has
more than 1 fallthru predecessor gets a label, and a goto is inserted
into a new block following each of those preds.  You don't get new basic
blocks forming all over the place until you specifically want them.

So you would then get:
BB1
  call X
BB13
  goto lab_bb2;
BB2			BB9
  lab_bb2		  exception
  <...>
 
BB12
  call X
BB15
  goto lab_bb2;

Now the IL and the CFG are in sync with a trivial amount of work, and
you didnt have to deal with new BB's until you needed them.

Is there a reason the insert_on_edge/commit_edge_insertions model, or
some variation,  wouldn't work for
block_replication/commit_block_replication() sequences?

Andrew


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