------- 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