This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Loop header copying
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?
> 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