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