Patchwork Scheduler cleanups, 5/5

login
register
mail settings
Submitter Bernd Schmidt
Date April 4, 2011, 11:14 p.m.
Message ID <4D9A50F2.7040404@codesourcery.com>
Download mbox | patch
Permalink /patch/89732/
State New
Headers show

Comments

Bernd Schmidt - April 4, 2011, 11:14 p.m.
On 03/24/2011 02:19 PM, Bernd Schmidt wrote:
> We can currently select an insn to be scheduled, only to find out that
> it's not actually valid at the current time, either due to state
> conflicts or being an asm with something else already scheduled in the
> same cycle. Not only is this pointless, it causes problem with the
> sched_reorder logic in the TI C6X port (which will be submitted later).
> The solution is to prune the ready list earlier. More code is moved out
> of the schedule_block main loop, which is IMO always a good thing.

This caused the mips64-linux failure in PR48403, and presumably also the
identical one on ia64.

We abort in max_issue because issue_rate is 2, and cycle_issued_insns is
3. It turns out that there was an unintended change in behaviour: it's
important to increment cycle_issued_insns only if state_transition
modifies the state. Insns with a "nothing" reservation don't count
against max_issue. The insns in question are potential_cprestore and
use_cprestore in the MIPS case.

The patch below fixes the testcase in the PR. I'll test
tonight/tomorrow, probably on mips64-elf. Ok if that passes?


Bernd
* haifa-sched.c (schedule_block): Increment cycle_issued_insns only
	if old and new states differ.
Eric Botcazou - April 5, 2011, 2:32 p.m.
> The patch below fixes the testcase in the PR. I'll test
> tonight/tomorrow, probably on mips64-elf. Ok if that passes?

I get back the comparison failure with it on IA-64/Linux:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/ada/a-elchha.o differs
gcc/ada/butil.o differs
gcc/ada/elists.o differs
gcc/ada/fmap.o differs
gcc/ada/ali.o differs
gcc/ada/fname.o differs
gcc/ada/fname-uf.o differs
gcc/ada/g-speche.o differs
gcc/ada/g-u3spch.o differs
gcc/ada/lib-util.o differs
gcc/ada/osint-c.o differs
gcc/ada/namet.o differs
gcc/ada/output.o differs
gcc/ada/osint.o differs
gcc/ada/s-os_lib.o differs
gcc/build/genhooks.o differs
gcc/build/genchecksum.o differs
libcpp/directives.o differs
libcpp/expr.o differs
libcpp/files.o differs
libcpp/lex.o differs
libcpp/mkdeps.o differs
libcpp/traditional.o differs
libdecnumber/decimal32.o differs
libdecnumber/decNumber.o differs
libiberty/pic/simple-object-coff.o differs
libiberty/pic/simple-object-elf.o differs
libiberty/pic/simple-object-mach-o.o differs
libiberty/pic/cplus-dem.o differs
libiberty/pic/cp-demangle.o differs
libiberty/pic/pex-common.o differs
libiberty/simple-object-coff.o differs
libiberty/simple-object-elf.o differs
libiberty/simple-object-mach-o.o differs
libiberty/cplus-dem.o differs
libiberty/md5.o differs
libiberty/sha1.o differs
libiberty/cp-demangle.o differs
libiberty/pex-common.o differs
lto-plugin/.libs/lto-plugin.o differs
zlib/libz_a-compress.o differs
zlib/libz_a-uncompr.o differs

This is an --enable-checking build.  For libiberty/pex-common.o:

@@ -1,5 +1,5 @@

-stage2-libiberty/pex-common.o:     file format elf64-ia64-little
+stage3-libiberty/pex-common.o:     file format elf64-ia64-little


 Disassembly of section .text:
@@ -1097,15 +1097,15 @@
     167c:      08 00 84 00                         br.ret.sptk.many b0;;

 0000000000001680 <pex_input_pipe>:
-    1680:      18 40 35 14 80 05       [MMB]       alloc r40=ar.pfs,13,10,0
-    1686:      c0 80 33 7e 46 00                   adds r12=-16,r12
-    168c:      00 00 00 20                         nop.b 0x0
-    1690:      01 70 c0 40 00 21       [MII]       adds r14=48,r32
-    1696:      70 02 00 62 00 20                   mov r39=b0
-    169c:      05 08 00 84                         mov r41=r1;;
-    16a0:      09 70 00 1c 10 10       [MMI]       ld4 r14=[r14]
-    16a6:      00 00 00 02 00 60                   nop.m 0x0
-    16ac:      84 01 01 84                         adds r35=24,r32;;
+    1680:      08 40 35 14 80 05       [MMI]       alloc r40=ar.pfs,13,10,0
+    1686:      c0 80 33 7e 46 e0                   adds r12=-16,r12
+    168c:      04 00 c4 00                         mov r39=b0
+    1690:      09 70 c0 40 00 21       [MMI]       adds r14=48,r32
+    1696:      90 02 04 00 42 60                   mov r41=r1
+    169c:      84 01 01 84                         adds r35=24,r32;;
+    16a0:      09 00 00 00 01 00       [MMI]       nop.m 0x0
+    16a6:      e0 00 38 20 20 00                   ld4 r14=[r14]
+    16ac:      00 00 04 00                         nop.i 0x0;;
     16b0:      11 30 00 1c 87 31       [MIB]       cmp4.lt p6,p7=0,r14
     16b6:      00 00 00 02 00 03                   nop.i 0x0
     16bc:      70 00 00 43                   (p06) br.cond.dpnt.few 1720 
<pex_input_pipe+0xa0>;;
@@ -1427,15 +1427,15 @@
     1d3c:      00 00 04 00                         nop.i 0x0

 0000000000001d40 <pex_get_status>:
-    1d40:      18 30 31 10 80 05       [MMB]       alloc r38=ar.pfs,12,8,0
-    1d46:      c0 80 33 7e 46 00                   adds r12=-16,r12
-    1d4c:      00 00 00 20                         nop.b 0x0
+    1d40:      08 30 31 10 80 05       [MMI]       alloc r38=ar.pfs,12,8,0
+    1d46:      c0 80 33 7e 46 a0                   adds r12=-16,r12
+    1d4c:      04 00 c4 00                         mov r37=b0
     1d50:      09 18 01 41 00 21       [MMI]       adds r35=64,r32
-    1d56:      40 82 81 00 42 a0                   adds r36=48,r32
-    1d5c:      04 00 c4 00                         mov r37=b0;;
-    1d60:      09 70 00 46 18 10       [MMI]       ld8 r14=[r35]
-    1d66:      00 00 00 02 00 e0                   nop.m 0x0
-    1d6c:      04 08 00 84                         mov r39=r1;;
+    1d56:      40 82 81 00 42 e0                   adds r36=48,r32
+    1d5c:      04 08 00 84                         mov r39=r1;;
+    1d60:      09 00 00 00 01 00       [MMI]       nop.m 0x0
+    1d66:      e0 00 8c 30 20 00                   ld8 r14=[r35]
+    1d6c:      00 00 04 00                         nop.i 0x0;;
     1d70:      11 38 00 1c 06 39       [MIB]       cmp.eq p7,p6=0,r14
     1d76:      00 00 00 02 80 03                   nop.i 0x0
     1d7c:      00 01 00 43                   (p07) br.cond.dpnt.few 1e70 
<pex_get_status+0x130>;;
Bernd Schmidt - April 5, 2011, 3:54 p.m.
On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>> The patch below fixes the testcase in the PR. I'll test
>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
> 
> I get back the comparison failure with it on IA-64/Linux:

Looking into it. I ran into PR48441, I assume you were using the patch
from that as well?


Bernd
Jeff Law - April 5, 2011, 4:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/11 09:54, Bernd Schmidt wrote:
> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>>> The patch below fixes the testcase in the PR. I'll test
>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
>>
>> I get back the comparison failure with it on IA-64/Linux:
> 
> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?
Bernd,

Any comparison failures with --disable-checking or
- --enable-checking=release configured trees should be sent my way.
There's a bug in a change of mine from last week which will cause these
kinds of problems.  No sense in you duplicating the work I've already
done to track those problems down.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmz5lAAoJEBRtltQi2kC7drwH/RnGeuX9h35n6N0tn9J0tWsy
iIM83r1Okh/1+YfT4MIpYAStY/tPMgvKoppiqXrqgB8lBHoEcY0I4E58GWjt2fI6
+rbhwPR3Fpc3Fn9/FM0K+ulHhFjPhgdvag/OI6PBXQzfXCdnS4gLUd2c5dEXDOFz
FnSjp6yPYP7GtTfaVJOj7vKvzYsvECI5FB+VJgSTDB1PNlhjTIDSU9VxDTWxvdXj
ywrwZiNr3fXrVMb9rJVrOk0nXVjkPaKq7GEmDxHeIaXxNZqOXc1il014/zObVDHe
aIaRLewui/19MX3OtJFPYeFCM9MqsAaip4JwgF/peSp9pjD+IzNct6k4k9riWwI=
=IBZn
-----END PGP SIGNATURE-----
Bernd Schmidt - April 5, 2011, 4:10 p.m.
On 04/05/2011 06:08 PM, Jeff Law wrote:
> On 04/05/11 09:54, Bernd Schmidt wrote:
>> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>>>> The patch below fixes the testcase in the PR. I'll test
>>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
>>>
>>> I get back the comparison failure with it on IA-64/Linux:
> 
>> Looking into it. I ran into PR48441, I assume you were using the patch
>> from that as well?
> Bernd,
> 
> Any comparison failures with --disable-checking or
> --enable-checking=release configured trees should be sent my way.
> There's a bug in a change of mine from last week which will cause these
> kinds of problems.  No sense in you duplicating the work I've already
> done to track those problems down.

Well, I need to test the scheduler patch posted three messages or so
previously, on either mips64 or ia64, so might as well try to bootstrap
on gcc60.


Bernd
Jeff Law - April 5, 2011, 4:15 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/11 10:10, Bernd Schmidt wrote:
> On 04/05/2011 06:08 PM, Jeff Law wrote:
>> On 04/05/11 09:54, Bernd Schmidt wrote:
>>> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>>>>> The patch below fixes the testcase in the PR. I'll test
>>>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
>>>>
>>>> I get back the comparison failure with it on IA-64/Linux:
>>
>>> Looking into it. I ran into PR48441, I assume you were using the patch
>>> from that as well?
>> Bernd,
>>
>> Any comparison failures with --disable-checking or
>> --enable-checking=release configured trees should be sent my way.
>> There's a bug in a change of mine from last week which will cause these
>> kinds of problems.  No sense in you duplicating the work I've already
>> done to track those problems down.
> 
> Well, I need to test the scheduler patch posted three messages or so
> previously, on either mips64 or ia64, so might as well try to bootstrap
> on gcc60.
In which case, if you're not using checking, you'll want the attached
patch to avoid comparison failures with --disable-checking.  I felt like
a bloody idiot when I finally saw what I'd done...




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNm0AgAAoJEBRtltQi2kC7UloH/1Z+zEV26u9m6FZ++57nXJbE
TedMoL+C/Kvefd2HBpIdN+Jgz+bsEgauOIyCbAuodhHbqkODDuIbdHmx6f5xn+V1
SjMWzCaxNiJdCinPYFqe/Mb1+hHz3s7iEsPjhj4EQ91Tx7/Xv/qPbU8qimSL6zhy
51l2RH+jNMgapHw+7QhMwVfY6oCI0hvbHMY6+Ly2oG16yxPt9RKJyp8o+q2zlFB1
WVD7EvkoaMg+wQAlXnV8scslKeoUE/aJOnGfOXnuaiEWPterE7Ku4JE8xz0P+PWA
k4JoBeII+vR89ofpXjeG1Ei0vzXQjFHKgPUxkfmNiWMhM6uioQ+PK/GVYW0YPkw=
=tiZC
-----END PGP SIGNATURE-----
Index: tree-ssa-threadupdate.c
===================================================================
*** tree-ssa-threadupdate.c	(revision 171989)
--- tree-ssa-threadupdate.c	(working copy)
*************** determine_bb_domination_status (struct l
*** 665,671 ****
    edge_iterator ei;
    edge e;
  
- #ifdef ENABLE_CHECKING
    /* This function assumes BB is a successor of LOOP->header.
       If that is not the case return DOMST_NONDOMINATING which
       is always safe.  */
--- 665,670 ----
*************** determine_bb_domination_status (struct l
*** 684,690 ****
        if (!ok)
  	return DOMST_NONDOMINATING;
      }
- #endif
  
    if (bb == loop->latch)
      return DOMST_DOMINATING;
--- 683,688 ----
Steve Ellcey - April 5, 2011, 4:41 p.m.
On Tue, 2011-04-05 at 17:54 +0200, Bernd Schmidt wrote:
> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
> >> The patch below fixes the testcase in the PR. I'll test
> >> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
> > 
> > I get back the comparison failure with it on IA-64/Linux:
> 
> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?
> 
> 
> Bernd

Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c
patch and r171988 and I got this error during stage 2:


/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 'create_
automata':
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal comp
iler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [build/genautomata.o] Error 1
make[3]: Leaving directory `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11.
23-trunk/obj_gcc/gcc'
make[2]: *** [all-stage2-gcc] Error 2

I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change this
error.

I don't seem to be able to reproduce this on IA64 Linux.

Steve Ellcey
sje@cup.hp.com
Steve Ellcey - April 5, 2011, 5:04 p.m.
On Tue, 2011-04-05 at 09:41 -0700, Steve Ellcey wrote:

> Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c
> patch and r171988 and I got this error during stage 2:
> 
> 
> /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 'create_
> automata':
> /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal comp
> iler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [build/genautomata.o] Error 1
> make[3]: Leaving directory `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11.
> 23-trunk/obj_gcc/gcc'
> make[2]: *** [all-stage2-gcc] Error 2
> 
> I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change this
> error.
> 
> I don't seem to be able to reproduce this on IA64 Linux.

I was able to reproduce it on my Linux system.  I thought my build had
already gotten past the point where this was happening but it hadn't.  I
get this on IA64 HP-UX and Linux with the proposed haifa-sched.c change.

Steve Ellcey
sje@cup.hp.com
Eric Botcazou - April 5, 2011, 5:48 p.m.
> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?

It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
patch... at least it was supposed to be, but I screwed up, sorry about that.

After having done another round of testing, let me recap:
  1. yesterday's pristine tree yields the bootstrap comparison failure on the 
IA-64/Linux machine,
  2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
bootstraps on the IA-64/Linux machine.
Steve Ellcey - April 5, 2011, 6:01 p.m.
On Tue, 2011-04-05 at 19:48 +0200, Eric Botcazou wrote:
> > Looking into it. I ran into PR48441, I assume you were using the patch
> > from that as well?
> 
> It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
> patch... at least it was supposed to be, but I screwed up, sorry about that.
> 
> After having done another round of testing, let me recap:
>   1. yesterday's pristine tree yields the bootstrap comparison failure on the 
> IA-64/Linux machine,
>   2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
> bootstraps on the IA-64/Linux machine.

What are the two patches to haifa-sched.c?  I have one patch to
schedule_block from
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html
but that patch (alone or with the Jeff Law patch) isn't working for me
on IA64 Linux.  Is there a second haifa-sched.c patch I should also
have?

Steve Ellcey
sje@cup.hp.com
Eric Botcazou - April 5, 2011, 6:18 p.m.
> What are the two patches to haifa-sched.c?  I have one patch to
> schedule_block from
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html
> but that patch (alone or with the Jeff Law patch) isn't working for me
> on IA64 Linux.  Is there a second haifa-sched.c patch I should also
> have?

No, the important point is that I'm using yesterday's tree, so the first patch 
is Bernd's patch from yesterday (r171942).
Steve Ellcey - April 5, 2011, 8:25 p.m.
On Tue, 2011-04-05 at 20:18 +0200, Eric Botcazou wrote:
> > What are the two patches to haifa-sched.c?  I have one patch to
> > schedule_block from
> > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html
> > but that patch (alone or with the Jeff Law patch) isn't working for me
> > on IA64 Linux.  Is there a second haifa-sched.c patch I should also
> > have?
> 
> No, the important point is that I'm using yesterday's tree, so the first patch 
> is Bernd's patch from yesterday (r171942).

OK, I was using a newer tree and I think the problem I ran into was PR
48441 which is now fixed in ToT.  I just updated my tree and that
problem seems to be fixed but now I can't compile dbxout.c (unused
variable error) so I still haven't managed a good bootstrap.

Steve Ellcey
sje@cup.hp.com


/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:107:12: error:
'debug_nesting' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:109:14: error:
'symbol_queue' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:110:12: error:
'symbol_queue_index' defined but not used [-Werror=unused-variable]
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/dbxout.c:111:12: error:
'symbol_queue_size' defined but not used [-Werror=unused-variable]
cc1: all warnings being treated as errors
Bernd Schmidt - April 5, 2011, 8:31 p.m.
On 04/05/2011 07:48 PM, Eric Botcazou wrote:
>> Looking into it. I ran into PR48441, I assume you were using the patch
>> from that as well?
> 
> It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
> patch... at least it was supposed to be, but I screwed up, sorry about that.
> 
> After having done another round of testing, let me recap:
>   1. yesterday's pristine tree yields the bootstrap comparison failure on the 
> IA-64/Linux machine,
>   2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
> bootstraps on the IA-64/Linux machine.

So, no problems with the extra haifa-sched.c patch from this thread?

My results are (today's tree + StevenB's patch from PR48441 + a revert
for froydnj's dbxout changes + my patch from this thread) yields
comparison failures. It sounds like you're saying these failures are
likely caused by something else?


Bernd
Steve Ellcey - April 5, 2011, 8:51 p.m.
On Tue, 2011-04-05 at 22:31 +0200, Bernd Schmidt wrote:
> On 04/05/2011 07:48 PM, Eric Botcazou wrote:
> >> Looking into it. I ran into PR48441, I assume you were using the patch
> >> from that as well?
> > 
> > It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
> > patch... at least it was supposed to be, but I screwed up, sorry about that.
> > 
> > After having done another round of testing, let me recap:
> >   1. yesterday's pristine tree yields the bootstrap comparison failure on the 
> > IA-64/Linux machine,
> >   2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
> > bootstraps on the IA-64/Linux machine.
> 
> So, no problems with the extra haifa-sched.c patch from this thread?
> 
> My results are (today's tree + StevenB's patch from PR48441 + a revert
> for froydnj's dbxout changes + my patch from this thread) yields
> comparison failures. It sounds like you're saying these failures are
> likely caused by something else?
> 
> 
> Bernd

I think you need Jeff Law's patch too to fix the comparision failures.

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00367.html

Steve Ellcey
sje@cup.hp.com
Eric Botcazou - April 5, 2011, 9:06 p.m.
> > After having done another round of testing, let me recap:
> >   1. yesterday's pristine tree yields the bootstrap comparison failure on
> > the IA-64/Linux machine,
> >   2. yesterday's pristine tree + your 2 patches to haifa-sched.c
> > successfully bootstraps on the IA-64/Linux machine.
>
> So, no problems with the extra haifa-sched.c patch from this thread?

Yes, with the 2 haifa-sched.c patches (r171942 + your patch from this thread) 
applied to yesterday's tree, IA-64/Linux bootstraps for me.  Without them, I 
get the comparison failures; with the first but not the second, I get the ICE 
on errors.c that Steve reported.

> My results are (today's tree + StevenB's patch from PR48441 + a revert
> for froydnj's dbxout changes + my patch from this thread) yields
> comparison failures. It sounds like you're saying these failures are
> likely caused by something else?

Yes, possibly, and there is still the other issue that Jeff is working on.

Given my results and that your patch from this thread apparently only restores 
the old behaviour, I'd install this patch.
Steve Ellcey - April 5, 2011, 10:15 p.m.
On Tue, 2011-04-05 at 23:06 +0200, Eric Botcazou wrote:

> Yes, possibly, and there is still the other issue that Jeff is working on.
> 
> Given my results and that your patch from this thread apparently only restores 
> the old behaviour, I'd install this patch.


I finally got a good bootstrap on IA64 HP-UX.  I used this patch, Jeff's
patch for PR 48444 (already checked in) and Nathan's patch for PR 48471.
So yes, I'd like to see this patch checked in too.

Steve Ellcey
sje@cup.hp.com
Bernd Schmidt - April 5, 2011, 10:19 p.m.
On 04/06/2011 12:15 AM, Steve Ellcey wrote:
> I finally got a good bootstrap on IA64 HP-UX.  I used this patch, Jeff's
> patch for PR 48444 (already checked in) and Nathan's patch for PR 48471.
> So yes, I'd like to see this patch checked in too.

Done.


Bernd

Patch

Index: haifa-sched.c
===================================================================
--- haifa-sched.c	(revision 171954)
+++ haifa-sched.c	(working copy)
@@ -3230,10 +3230,12 @@  schedule_block (basic_block *target_bb)
 
 	  if (recog_memoized (insn) >= 0)
 	    {
+	      memcpy (temp_state, curr_state, dfa_state_size);
 	      cost = state_transition (curr_state, insn);
 	      if (!flag_sched_pressure)
 		gcc_assert (cost < 0);
-	      cycle_issued_insns++;
+	      if (memcmp (temp_state, curr_state, dfa_state_size) != 0)
+		cycle_issued_insns++;
 	      asm_p = false;
 	    }
 	  else