[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

["abel at ispras dot ru" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #11 from abel at ispras dot ru  2008-09-05 09:16 -------
I was unable to trigger the assert on the given testcase even with the
cross-compiler configured exactly like the one in the bug report.  However, I
was able to reproduce the ICE on a longer plain C test case.  

The assert that triggers actually means that we will never issue more insns on
a cycle than issue_rate, i.e. cycle_issued_insns is always <= issue_rate. 
However, both before and after selective scheduling merge, I see (the log is
given for the trunk just before sel-sched merge):

;;      Ready list (t =   0):    117  101  100
;;              Choosed insn : 100; points: 3/3
;;        0-->   100 $2=sxn([$18])                     :sb1_ls0|sb1_ls1
;;              dependencies resolved: insn 104
;;              Ready-->Q: insn 104: queued for 1 cycles.
;;              tick updated: insn 104 into queue with cost=1
;;              dependencies resolved: insn 118
;;              tick updated: insn 118 into ready
;;      Ready list (t =   0):    118  117  101
;;              Choosed insn : 101; points: 3/2
;;        0-->   101 $16=sxn([$17])                    :sb1_ls0|sb1_ls1
;;              dependencies resolved: insn 119
;;              tick updated: insn 119 into ready
;;      Ready list (t =   0):    119  118  117
;;              Choosed insn : 117; points: 2/1
;;        0-->   117 $19=$19+0x1                       :sb1_ls1|sb1_ex1|sb1_ex0
;;      Ready list (t =   0):    119  118
;;              Choosed insn : 118; points: 1/1
;;        0-->   118 $18=$18+0x1                       :sb1_ls1|sb1_ex1|sb1_ex0
;;      Ready list (t =   0):    119
;;              Choosed insn : 119; points: -1/1

<assert is triggered here after the merge>

;;              Ready-->Q: insn 119: queued for 1 cycles.

This means that we've issued insns 100, 101, 117, and 118, while at the same
time claiming that issue_rate is 3.  In mips_issue_rate, I see the following:

    case PROCESSOR_SB1:
    case PROCESSOR_SB1A:
      /* This is actually 4, but we get better performance if we claim 3.
         This is partly because of unwanted speculative code motion with the
         larger number, and partly because in most common cases we can't
         reach the theoretical max of 4.  */
      return 3;

So this is while the assert is triggered only for those arches.  

The assert was introduced with sel-sched merge just for purposes of stricter
checking.  I was not aware of targets that claim issue rate which is lower than
the maximal value that can be actually achieved.  I see that it is done on
purpose, however hackish it may seem though.  So I'd propose to remove the
assert in max_issue and add a comment saying that for some targets the assert
may not be true.  If people are happy with this, I will prepare a patch.

The other solution will be to fix mips.c to make it not to lie to the scheduler
about its issue rate, and fix the performance issues with e.g. lowering
priority of speculative motions in the appropriate scheduler hooks.  But I
believe that this is not appropriate for stage3. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360