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

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

[John David Anglin]

> Infinite loop occurs compiling nm.c (binutils 2.12.90
> 20020404).  The final loop in dbr_sequence loops forever
> because of a loop in the insn chain that occurs compiling
> the function filter_symbols.  The insn chain appears ok
> when dbr_sequence is called.

This is what is causing the problem.  There is a millicode call
insn in the function "return" just before the epilogue begin note.
dbr_schedule puts the first insn in the epilogue into the delay
slot of the call.  This insn restores %r2 from the stack.  It's
probably ok to put it into the delay slot of the millicode call
since it doesn't use %r2, but the start of the epilogue is now
in an indeterminate position.  reposition_prologue_and_epilogue_notes
moves the epilogue begin note before the sequence.  However, in
fixing the insn chain, it apparently doesn't check for a sequence
and the chain is left in a corrupt state.  In particular, it doesn't
touch the numbering inside the sequence.

I probably can fix this by adding a blockage at the beginning
of the epilogue.  However, this seems like overkill and simply
avoids the problem.

Suggestions?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

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

[law]

In message <200204051935.g35JZdxl014766@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > Infinite loop occurs compiling nm.c (binutils 2.12.90
 > > 20020404).  The final loop in dbr_sequence loops forever
 > > because of a loop in the insn chain that occurs compiling
 > > the function filter_symbols.  The insn chain appears ok
 > > when dbr_sequence is called.
 > 
 > This is what is causing the problem.  There is a millicode call
 > insn in the function "return" just before the epilogue begin note.
 > dbr_schedule puts the first insn in the epilogue into the delay
 > slot of the call.  This insn restores %r2 from the stack.  It's
 > probably ok to put it into the delay slot of the millicode call
 > since it doesn't use %r2, but the start of the epilogue is now
 > in an indeterminate position.  reposition_prologue_and_epilogue_notes
 > moves the epilogue begin note before the sequence.  However, in
 > fixing the insn chain, it apparently doesn't check for a sequence
 > and the chain is left in a corrupt state.  In particular, it doesn't
 > touch the numbering inside the sequence.
 > 
 > I probably can fix this by adding a blockage at the beginning
 > of the epilogue.  However, this seems like overkill and simply
 > avoids the problem.
 > 
 > Suggestions?
I think reposition_prologue_and_epilogue_notes really needs to understand
SEQUENCEs and deal with them properly.  

jeff

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

[John David Anglin]

> I think reposition_prologue_and_epilogue_notes really needs to understand
> SEQUENCEs and deal with them properly.  

This is what was done <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00354.html>.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

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

[David S. Miller]

   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?

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.

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.

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

[law]

 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

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

[David S. Miller]

   From: law@redhat.com
   Date: Tue, 04 Jun 2002 14:46:53 -0600

    > 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.
   
Pre-delay slots fall right out of that too :-)

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

[John David Anglin]

> in an indeterminate position.  reposition_prologue_and_epilogue_notes
> moves the epilogue begin note before the sequence.  However, in
> fixing the insn chain, it apparently doesn't check for a sequence
> and the chain is left in a corrupt state.  In particular, it doesn't
> touch the numbering inside the sequence.

reposition_prologue_and_epilogue_notes uses reorder_insns.  The comments
for reorder_insns_nobb indicate that it doesn't know about sequences
and it looks like the same is true for reorder_insns.  Thus, it can't
be used at this point.

Do we actually need to call reposition_prologue_and_epilogue_notes
at this point?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

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

[Richard Henderson]

On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> Do we actually need to call reposition_prologue_and_epilogue_notes
> at this point?

Dunno.  Probably not.


r~

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

[John David Anglin]

> On Fri, Apr 05, 2002 at 02:54:08PM -0500, John David Anglin wrote:
> > Do we actually need to call reposition_prologue_and_epilogue_notes
> > at this point?

My conclusion is that we can't reposition prologue and epilogue notes
at this point in dbr_schedule because the above function can't handle
sequences.  Further, the exact end and start of the prologue and
epilogue, respectively, is indeterminant.  Thus, I propose that the
notes not be repositioned.

I have confirmed that the enclosed patch fixes the compilation problem
of nm.c under hppa-linux.  I have bootstrapped and checked that there
are no regressions with this patch under hppa-linux and
hppa2.0w-hp-hpux11.11.

The compilation failure of nm.c is a regression from 3.0.x.  OK for
trunk and 3.1 branch?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-04-06  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.

Index: reorg.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/reorg.c,v
retrieving revision 1.70
diff -u -3 -p -r1.70 reorg.c
--- reorg.c	31 Mar 2002 18:45:21 -0000	1.70
+++ reorg.c	6 Apr 2002 02:18:27 -0000
@@ -3686,10 +3686,6 @@ dbr_schedule (first, file)
   /* It is not clear why the line below is needed, but it does seem to be.  */
   unfilled_firstobj = (rtx *) obstack_alloc (&unfilled_slots_obstack, 0);
 
-  /* Reposition the prologue and epilogue notes in case we moved the
-     prologue/epilogue insns.  */
-  reposition_prologue_and_epilogue_notes (first);
-
   if (file)
     {
       int i, j, need_comma;

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

[Richard Henderson]

On Sat, Apr 06, 2002 at 03:12:23PM -0500, John David Anglin wrote:
> 	* reorg.c (dbr_schedule): Don't reposition prologue and epilogue notes.

Ok.


r~