[tree-ssa] Loop header copying

[Jan Hubicka]

> Hello,
> 
> > > Index: cfghooks.h
> > > ===================================================================
> > > RCS file: /cvs/gcc/gcc/gcc/cfghooks.h,v
> > > retrieving revision 1.1.2.6
> > > diff -c -3 -p -r1.1.2.6 cfghooks.h
> > > *** cfghooks.h	3 Nov 2003 17:47:35 -0000	1.1.2.6
> > > --- cfghooks.h	8 Dec 2003 20:28:03 -0000
> > > *************** struct cfg_hooks
> > > *** 51,56 ****
> > > --- 51,62 ----
> > >     /* Split basic block B after specified instruction I.  */
> > >     edge (*split_block) (basic_block b, void * i);
> > >   
> > > +   /* Split basic block B immediatelly after labels.  */
> > > +   edge (*split_block_after_labels) (basic_block b);
> > > + 
> > > +   /* Move block B immediatelly after block A.  */
> > > +   void (*move_block_after) (basic_block b, basic_block a);
> > > + 
> > 
> > I see there is no entry for duplicate_block, but that is just an
> > ommision.  Please add it there (either by update of this patch or
> > incrementally depending whehter you will need new revision of it).
> > This is definitly something we want to hookize.
> 
> OK.
> 
> > I am not very happy about move_block_after hook.  If it exists, it
> > should be somewhat unified with cfglayout way of reordering, but it
> > probably ought not be needed at first place.  We shall be completely
> > independent on the order of BBS on tree level...
> 
> We basically are; however keeping the things in logical order improves
> readability of the dumps and decreases the number of jump_insns emitted
> during rtl expansion.  I also try to keep the old loop optimizer happy.
> 
> > Hmm perhaps it is because you want loops to be lienar regions at RTL
> > evel.  This problem seems to be more general as we do create basic
> > blocks in arbitrary order now
> 
> Where?A
Hmm, I tought edge splitting was doing so, but I now recall that I've
"fixed" that at time we needed it for fallthru edges by adding after
argument to create_bb.  We should be safe now.

Still I am not quite sure we want to maintain "sane orderings" this way
become increasingly dificult when we get into busyness of more agressive
control flow changes and it is relatively easy and cheap to sanify the
ordering on very end of SSA compilation queue.

On RTL we do have some ordering fixup code in both tracer and loop
optimized and it is not too nasty, but it would be nicer to simply not
worry about it at all.

Concerning the dumps we can either "sanify" the order before dumping or
we can get into busyness of structuralizing of them so they are more
readable overall.  Jeff didn't like the idea of using structural
analysis code for dumping.  You mentioned you had some patch for this,
perhaps you can send it out as it is probably less involved than full
structural analysis...

Honza
> 
> > so if we want to be serious about RTL loop
> > optimizer we need to reorder blocks during emiting the loop notes, but I
> > guess it is moot unless your plans to rewrite cfgloop fails miserably
> > (and that would be real disaster so I hope it won't happen). 
> 
> Zdenek