Re: DFA scheduler patch for review

[law at redhat dot com]

 In message <20020430180326.GY18000@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
writes:
 > > Can you describe in a little more detail what you've done?  It's likely we
 > > can use it to simply replace the lame code from Haifa.
 > 
 > I am basically refering to schedule-ebbs done by Bernd.  Unlike haifa it is
 > threading whole superblock (I am not sure where the EBB in name comes from) 
EBB is an "extended basic block".  In simplest terms an EBB is a maximal set
of basic blocks with a single entry, but with multiple exits.  EBBs are rooted
at the entry block and all joiner nodes.

 > single basic block making the schedule better (I believe Haifa only moves
 > around the loads, so I get just very few intrablock moves from haifa).
No, haifa moves around random computation insns, in fact, it moves a hell
of a lot more random computation insns than it does loads.  Reason?  It's
much easier to prove movement of a computation insn is safe.  Proving a
load is safe is much harder.

Haifa has a lot of code to prove when moving loads are safe.  Unfortunately
it's painfully broken and should be completely ripped out.


 > I would expect better results from trace scheduling than from the haifa, 
but I
 > really don't know yet. 
I would much rather see us scheduling EBBS (or superblocks) before looking
a something like trace scheduling.  It would also be in our best interest
to look at T1/T2 reductions to build a global scheduler once the EBB/superblock
scheme is in place and working.

Extending from a solid EBB/superblock implementation to traces is relatively 
easy,
particularly when you restrict traces to not include joiner nodes (which 
greatly
reduces the amount of compensation code in trace scheduling).  You'd want to
do this is you have good profiling data.

 > When you do intrablock moves you may create new basic blocks (for instance
 > by moving partially dead code after the condtional jump and before following
 > label), kill basic block (by moving everything before preceeding 
conditional)
 > and you move the basic block boundaries.
Huh?  That wouldn't create a new block.  The insn moves into the fall-through
block.  If you're trying to move it to a critical edge, then you'd create
a new block, but that seems highly unlikely given the way the scheduler is
designed to work.

It seems to me you just need to update the head/end pointers.  This doesn't
actually change the structure of the CFG.

jeff