Some regressions from the dataflow merge

Some regressions from the dataflow merge

[Richard Guenther]

On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
on x86_64 some performance regressions with Botan (a collection of
cryptographic algorithms (see 
http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
small enough to investigate, but wait another day in case its just noise.

Otherwise things look smooth as expected.

Richard.

Re: Some regressions from the dataflow merge

[Kenneth Zadeck]

Richard Guenther wrote:
> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> on x86_64 some performance regressions with Botan (a collection of
> cryptographic algorithms (see 
> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> small enough to investigate, but wait another day in case its just noise.
>
> Otherwise things look smooth as expected.
>
> Richard.
>   
I looked at the graphs here and i do not see a regression except in the
compile time.

kenny

Re: Some regressions from the dataflow merge

[Richard Guenther]

On Tue, 12 Jun 2007, Kenneth Zadeck wrote:

> Richard Guenther wrote:
> > On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> > on x86_64 some performance regressions with Botan (a collection of
> > cryptographic algorithms (see 
> > http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> > small enough to investigate, but wait another day in case its just noise.
> >
> > Otherwise things look smooth as expected.
> >
> > Richard.
> >   
> I looked at the graphs here and i do not see a regression except in the
> compile time.

Note the graphs are for Throughput, so higher numbers are better.  Look
for example at Serpent or Skipjack at
http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
(which has separate graphs for each algorithm).  But as I said - just
wait a day to see if it is noise.

Richard.

RE: Some regressions from the dataflow merge

[Dave Korn]

On 12 June 2007 15:05, Kenneth Zadeck wrote:

> Richard Guenther wrote:
>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>> on x86_64 some performance regressions with Botan (a collection of
>> cryptographic algorithms (see
>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably small
>> enough to investigate, but wait another day in case its just noise. 
>> 
>> Otherwise things look smooth as expected.
>> 
>> Richard.
>> 
> I looked at the graphs here and i do not see a regression except in the
> compile time.

  Fortran has a testcase that trips one on x86/cygwin: see
http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html.  Perhaps you can comment on
whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Some regressions from the dataflow merge

[Kenneth Zadeck]

Richard Guenther wrote:
> On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
>
>   
>> Richard Guenther wrote:
>>     
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see 
>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
>>> small enough to investigate, but wait another day in case its just noise.
>>>
>>> Otherwise things look smooth as expected.
>>>
>>> Richard.
>>>   
>>>       
>> I looked at the graphs here and i do not see a regression except in the
>> compile time.
>>     
>
> Note the graphs are for Throughput, so higher numbers are better.  Look
> for example at Serpent or Skipjack at
> http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
> (which has separate graphs for each algorithm).  But as I said - just
> wait a day to see if it is noise.
>
> Richard.
>   
this is a different set of graphs than you sent the first time.  now i
see the regressions.

i will add this to the growing set of things to look at.

kenny

Re: Some regressions from the dataflow merge

[Richard Guenther]

On Tue, 12 Jun 2007, Kenneth Zadeck wrote:

> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> >
> >   
> >> Richard Guenther wrote:
> >>     
> >>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> >>> on x86_64 some performance regressions with Botan (a collection of
> >>> cryptographic algorithms (see 
> >>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> >>> small enough to investigate, but wait another day in case its just noise.
> >>>
> >>> Otherwise things look smooth as expected.
> >>>
> >>> Richard.
> >>>   
> >>>       
> >> I looked at the graphs here and i do not see a regression except in the
> >> compile time.
> >>     
> >
> > Note the graphs are for Throughput, so higher numbers are better.  Look
> > for example at Serpent or Skipjack at
> > http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html
> > (which has separate graphs for each algorithm).  But as I said - just
> > wait a day to see if it is noise.
> >
> > Richard.
> >   
> this is a different set of graphs than you sent the first time.  now i
> see the regressions.

I just pointed you to the start page initially - clicking the graphs
will reveal these details.

Sorry for that,
Richard.

Re: Some regressions from the dataflow merge

[Kenneth Zadeck]

Dave Korn wrote:
> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>
>   
>> Richard Guenther wrote:
>>     
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see
>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably small
>>> enough to investigate, but wait another day in case its just noise. 
>>>
>>> Otherwise things look smooth as expected.
>>>
>>> Richard.
>>>
>>>       
>> I looked at the graphs here and i do not see a regression except in the
>> compile time.
>>     
>
>   Fortran has a testcase that trips one on x86/cygwin: see
> http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html.  Perhaps you can comment on
> whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL?
>
>
>     cheers,
>       DaveK
>   
From what i can gather from looking at the "stacktrace", the problem is that
ix86_eax_live_at_start_p is only called on cigwin and of course we did
not check cigwin. 

This is an easy fix.

Change the macro "DF_LIVE_OUT" in this function to the function call
"df_get_live_out".  It takes the same parameter and returns the same thing.

I believe this will fix the problem.

kenny

RE: Some regressions from the dataflow merge

[Dave Korn]

On 12 June 2007 15:55, Kenneth Zadeck wrote:

> Dave Korn wrote:
>> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>>> Richard Guenther wrote:
>>> 
>>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>>> on x86_64 some performance regressions with Botan (a collection of
>>>> cryptographic algorithms (see
>>>> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
>>>> small enough to investigate, but wait another day in case its just
>>>> noise.  
>>>> 
>>>> Otherwise things look smooth as expected.
>>>> 
>>>> Richard.

>>> I looked at the graphs here and i do not see a regression except in the
>>> compile time. 

>>   Fortran has a testcase that trips one on x86/cygwin: see
>> http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html.  Perhaps you can comment
>> on whether df_live (== df->problems_by_index[DF_LIVE]) should ever be 
>> NULL?

> From what i can gather from looking at the "stacktrace", the problem is that
> ix86_eax_live_at_start_p is only called on cigwin and of course we did
> not check cigwin.
> 
> This is an easy fix.
> 
> Change the macro "DF_LIVE_OUT" in this function to the function call
> "df_get_live_out".  It takes the same parameter and returns the same thing.
> 
> I believe this will fix the problem.


  Thanks for the advice Kenny.  CC'ing the Fortran list because I don't have
time to put into this right away:  Paul or FX, perhaps you'd like to give that
advice a try?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Some regressions from the dataflow merge

[Richard Guenther]

On Tue, 12 Jun 2007, Richard Guenther wrote:

> 
> On ia64 SPEC2000 I see fma3d and applu now miscompare.

On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:

/gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o 
zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> 
fdo_make_pass2.err | tee fdo_make_pass2.out':
zgemm.f: In function 'zgemm':
zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Likewise for 176.gcc:

combine.c: In function 'simplify_comparison':
combine.c:9697: internal compiler error: in remove_insn, at 
emit-rtl.c:3597
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [combine.o] Error 1

Richard.

Re: Some regressions from the dataflow merge

[Seongbae Park (박성배, 朴成培)]

On 6/12/07, Richard Guenther <rguenther@suse.de> wrote:
> On Tue, 12 Jun 2007, Richard Guenther wrote:
>
> >
> > On ia64 SPEC2000 I see fma3d and applu now miscompare.
>
> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>
> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> fdo_make_pass2.err | tee fdo_make_pass2.out':
> zgemm.f: In function 'zgemm':
> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Likewise for 176.gcc:
>
> combine.c: In function 'simplify_comparison':
> combine.c:9697: internal compiler error: in remove_insn, at
> emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> specmake: *** [combine.o] Error 1

Sounds like there's a pass that are emitting a barrier during cfglayout mode.
I'll look at them.
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"

Re: Some regressions from the dataflow merge

[Kenneth Zadeck]

Seongbae Park (???, ???) wrote:
> On 6/12/07, Richard Guenther <rguenther@suse.de> wrote:
>> On Tue, 12 Jun 2007, Richard Guenther wrote:
>>
>> >
>> > On ia64 SPEC2000 I see fma3d and applu now miscompare.
>>
>> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>>
>> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
>> zscal.o -fprofile-use -O2 -ffast-math zscal.f
>> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
>> fdo_make_pass2.err | tee fdo_make_pass2.out':
>> zgemm.f: In function 'zgemm':
>> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>
>> Likewise for 176.gcc:
>>
>> combine.c: In function 'simplify_comparison':
>> combine.c:9697: internal compiler error: in remove_insn, at
>> emit-rtl.c:3597
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>> specmake: *** [combine.o] Error 1
>
> Sounds like there's a pass that are emitting a barrier during
> cfglayout mode.
> I'll look at them.
see if danny accidently reverted your gcse fix for this

kenny

Re: Some regressions from the dataflow merge

[Kenneth Zadeck]

Richard Guenther wrote:
> On Tue, 12 Jun 2007, Richard Guenther wrote:
>
>   
>> On ia64 SPEC2000 I see fma3d and applu now miscompare.
>>     
>
> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>
> /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o 
> zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> 
> fdo_make_pass2.err | tee fdo_make_pass2.out':
> zgemm.f: In function 'zgemm':
> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> Likewise for 176.gcc:
>
> combine.c: In function 'simplify_comparison':
> combine.c:9697: internal compiler error: in remove_insn, at 
> emit-rtl.c:3597
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> specmake: *** [combine.o] Error 1
>
> Richard.
>   
Richard,

did these two regression go away?  We committed a change to gcse that
should have fixed this bug.

kenny

Re: Some regressions from the dataflow merge

[Richard Guenther]

On 6/13/07, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> >
> > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> > zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
> > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > zgemm.f: In function 'zgemm':
> > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> >
> > Likewise for 176.gcc:
> >
> > combine.c: In function 'simplify_comparison':
> > combine.c:9697: internal compiler error: in remove_insn, at
> > emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > specmake: *** [combine.o] Error 1
> >
> > Richard.
> >
> Richard,
>
> did these two regression go away?  We committed a change to gcse that
> should have fixed this bug.

Sorry, we have to wait another day - the placement new patch caused
conflicts on svn update on the tree (DAMN IDENTICAL LOCAL FILES
CONFLICTS - svn sucks).  I'll keep you posted if they still fail after
the gcse patch.

Richard.

Re: Some regressions from the dataflow merge

[Richard Guenther]

On Wed, 13 Jun 2007, Kenneth Zadeck wrote:

> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Richard Guenther wrote:
> >
> >   
> >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> >>     
> >
> > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> >
> > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o 
> > zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
> > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> 
> > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > zgemm.f: In function 'zgemm':
> > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> >
> > Likewise for 176.gcc:
> >
> > combine.c: In function 'simplify_comparison':
> > combine.c:9697: internal compiler error: in remove_insn, at 
> > emit-rtl.c:3597
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > specmake: *** [combine.o] Error 1
> >
> > Richard.
> >   
> Richard,
> 
> did these two regression go away?  We committed a change to gcse that
> should have fixed this bug.

These two are gone now.  The ia64 miscompares still are there.

Richard.

Re: Some regressions from the dataflow merge

[Seongbae Park (박성배, 朴成培)]

On 6/14/07, Richard Guenther <rguenther@suse.de> wrote:
> On Wed, 13 Jun 2007, Kenneth Zadeck wrote:
>
> > Richard Guenther wrote:
> > > On Tue, 12 Jun 2007, Richard Guenther wrote:
> > >
> > >
> > >> On ia64 SPEC2000 I see fma3d and applu now miscompare.
> > >>
> > >
> > > On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
> > >
> > > /gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
> > > zscal.o        -fprofile-use         -O2 -ffast-math  zscal.f
> > > Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2>
> > > fdo_make_pass2.err | tee fdo_make_pass2.out':
> > > zgemm.f: In function 'zgemm':
> > > zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > >
> > > Likewise for 176.gcc:
> > >
> > > combine.c: In function 'simplify_comparison':
> > > combine.c:9697: internal compiler error: in remove_insn, at
> > > emit-rtl.c:3597
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> > > specmake: *** [combine.o] Error 1
> > >
> > > Richard.
> > >
> > Richard,
> >
> > did these two regression go away?  We committed a change to gcse that
> > should have fixed this bug.
>
> These two are gone now.  The ia64 miscompares still are there.

I'm looking at it. It is either a scheduler problem,
or some other problem downstream triggered by the scheduler.
However, I'm having hard time adding fine-grained dbg_cnt to our scheduler
- do you know who might be interested in adding insn level
dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :(
-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"

Re: Some regressions from the dataflow merge

[Maxim Kuvyrkov]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

Seongbae Park (???, ???) wrote:

...

> I'm looking at it. It is either a scheduler problem,
> or some other problem downstream triggered by the scheduler.
> However, I'm having hard time adding fine-grained dbg_cnt to our scheduler
> - do you know who might be interested in adding insn level
> dbg_cnt in the scheduler ? Current dbg_cnt (sched_insn) causes ICE :(

IMHO, the least intrusive way of using a debug counter in scheduler is 
to place into instruction choosing module and make scheduler to chose 
next instruction at all times.  I have successfully used this technique 
in debugging selective scheduler and believe it will suit haifa 
scheduler perfectly.

I've attached a patch that moves dbg_cnt to choose_ready () routine, but 
at this point have no time to test it for usability (though it compiles 
fine on x86_64).  If the patch won't work please let me know and I'll 
fix it during the weekend.


Regards,

Maxim

[-- Attachment #2: sched-dbg-cnt.patch --]
[-- Type: text/x-patch, Size: 4133 bytes --]

Index: haifa-sched.c
===================================================================
--- haifa-sched.c	(revision 125737)
+++ haifa-sched.c	(working copy)
@@ -539,7 +539,7 @@ static rtx ready_remove (struct ready_li
 static void ready_remove_insn (rtx);
 static int max_issue (struct ready_list *, int *, int);
 
-static rtx choose_ready (struct ready_list *);
+static int choose_ready (struct ready_list *, rtx *);
 
 static void fix_inter_tick (rtx, rtx);
 static int fix_tick_ready (rtx);
@@ -1980,17 +1980,42 @@ max_issue (struct ready_list *ready, int
 
 /* The following function chooses insn from READY and modifies
    *N_READY and READY.  The following function is used only for first
-   cycle multipass scheduling.  */
-
-static rtx
-choose_ready (struct ready_list *ready)
+   cycle multipass scheduling.
+   Return:
+   -1 if cycle should be advanced,
+   0 if INSN_PTR is set to point to the desirable insn,
+   1 if choose_ready () should be restarted without advancing the cycle.  */
+static int
+choose_ready (struct ready_list *ready, rtx *insn_ptr)
 {
-  int lookahead = 0;
+  int lookahead;
+
+  if (dbg_cnt (sched_insn) == false)
+    {
+      rtx insn;
+
+      insn = NEXT_INSN (last_scheduled_insn);
+
+      if (QUEUE_INDEX (insn) == QUEUE_READY)
+	/* INSN is in the ready_list.  */
+	{
+	  *insn_ptr = insn;
+	  return 0;
+	}
+
+      /* INSN is in the queue.  Advance cycle to move it to the ready list.  */
+      return -1;
+    }
+
+  lookahead = 0;
 
   if (targetm.sched.first_cycle_multipass_dfa_lookahead)
     lookahead = targetm.sched.first_cycle_multipass_dfa_lookahead ();
   if (lookahead <= 0 || SCHED_GROUP_P (ready_element (ready, 0)))
-    return ready_remove_first (ready);
+    {
+      *insn_ptr = ready_remove_first (ready);
+      return 0;
+    }
   else
     {
       /* Try to choose the better insn.  */
@@ -2007,7 +2032,10 @@ choose_ready (struct ready_list *ready)
 	}
       insn = ready_element (ready, 0);
       if (INSN_CODE (insn) < 0)
-	return ready_remove_first (ready);
+	{
+	  *insn_ptr = ready_remove_first (ready);
+	  return 0;
+	}
 
       if (spec_info
 	  && spec_info->flags & (PREFER_NON_DATA_SPEC
@@ -2049,7 +2077,7 @@ choose_ready (struct ready_list *ready)
 	   list.  */
 	{
 	  change_queue_index (insn, 1);
-	  return 0;
+	  return 1;
 	}
 
       max_points = ISSUE_POINTS (insn);
@@ -2071,9 +2099,15 @@ choose_ready (struct ready_list *ready)
 	}
 
       if (max_issue (ready, &index, max_points) == 0)
-	return ready_remove_first (ready);
+	{
+	  *insn_ptr = ready_remove_first (ready);
+	  return 0;
+	}
       else
-	return ready_remove (ready, index);
+	{
+	  *insn_ptr = ready_remove (ready, index);
+	  return 0;
+	}
     }
 }
 
@@ -2271,29 +2305,22 @@ schedule_block (basic_block *target_bb, 
 	      || !(*current_sched_info->schedule_more_p) ())
 	    break;
 
-          if (dbg_cnt (sched_insn) == false)
-            {
-              insn = NEXT_INSN (last_scheduled_insn); 
-              while ((*current_sched_info->schedule_more_p) ())
-                {
-                  (*current_sched_info->begin_schedule_ready) (insn,
-                                                               last_scheduled_insn);
-                  if (QUEUE_INDEX (insn) >= 0)
-                    queue_remove (insn);
-                  last_scheduled_insn = insn;
-                  insn = NEXT_INSN (insn);
-                }
-              while (ready.n_ready)
-                ready_remove_first (&ready);
-              goto bail_out;
-            }
-
 	  /* Select and remove the insn from the ready list.  */
 	  if (sort_p)
 	    {
-	      insn = choose_ready (&ready);
-	      if (!insn)
+	      int res;
+
+	      insn = NULL_RTX;
+	      res = choose_ready (&ready, &insn);
+
+	      if (res < 0)
+		/* Finish cycle.  */
+		break;
+	      if (res > 0)
+		/* Restart choose_ready ().  */
 		continue;
+
+	      gcc_assert (insn != NULL_RTX);
 	    }
 	  else
 	    insn = ready_remove_first (&ready);
@@ -2445,7 +2472,6 @@ schedule_block (basic_block *target_bb, 
 	}
     }
 
-bail_out:
   /* Debug info.  */
   if (sched_verbose)
     {