Re: middle-end/6180: Infinite loop in cc1 during dbr pass

[law@redhat.com]

 In message <20020604.125117.48806435.davem@redhat.com>, "David S. Miller" 
writes:
 >    From: law@redhat.com
 >    Date: Tue, 04 Jun 2002 13:26:44 -0600
 > 
 >    I think reposition_prologue_and_epilogue_notes really needs to
 >    understand SEQUENCEs and deal with them properly.  
 > 
 > This reminds me, why do we really put the delay slot stuff
 > in SEQUENCES?
Because that's the way someone wrote it back in 1988? :(


 > I think we could handle that problem (keeping the insn and it's delay
 > slots together and figuring out that an insn is "inside" a delay slot)
 > in some other clean way.
I don't think it'd be terribly hard to use a flag bit to tell us this.


 > This could also, for example, make it much more easier to teach the
 > generic instruction scheduler how to do delay slotting so we can
 > obliterate reorg.
Oh man.  Zapping reorg is conceptually simple if you look at it from
the right angle (ie dependency graphs).  It'd also be a hell of a lot
faster.

The whole trick is to use the dependency graph to give us the set of
potential instructions which can be used to fill any particular delay
slot.  This avoids all the sillyness of resource tracking through entire
basic blocks as implemented in reorg right now.

When searching backwards from the delay slot, you look for leaves in the
graph, when searching forward, you look for roots in the graph.  Those
are the only interesting insns.

[ OK, so that's over-simplified in the case of calls and normal insns
  with delay slots -- you need to prune out all the instructions before
  the call when you start searching for roots. ]

Anyway, with the candidate sets, you just call back into the insn-attrtab
routines to see which one actually works. 

jeff