On Mon, Nov 25, 2013 at 2:08 AM, Alexander Monakov <amona...@ispras.ru> wrote: > On Sat, 23 Nov 2013, Wei Mi wrote: >> For the failed testcase, it was compiled using -fmodulo-sched. >> modulo-sched phase set SCHED_GROUP_P of a jump insn to be true, which >> means the jump insn should be scheduled with prev insn as a group. > > SMS doesn't set SCHED_GROUP_P by itself; did you mean that SCHED_GROUP_P is > set by dependency analysis code similar to sched2? >
SCHED_GROUP_P is set in sched_analyze for "call + return value" group and other groups, and in sched_init for macrofusion. Both sched_analyze and sched_init are used by SMS (sched_analyze is used by creating ddg). I think sched1 may have the same problem when it set SCHED_GROUP_P and sched2 uses it. >> When modulo scheduling is finished, the flag of SCHED_GROUP_P is not >> cleaned up. After that, pass_jump2 phase split the bb and move the >> prev insn to another bb. Then pass_sched2 see the flag and mistakenly >> try to bind the jump insn with a code label. > > I think the analysis is incomplete. Looking at the backtrace posted in the > bug report, the failure path goes through chain_to_prev_insn, which protects > against such failure: > > prev_nonnote = prev_nonnote_nondebug_insn (insn); > if (BLOCK_FOR_INSN (insn) == BLOCK_FOR_INSN (prev_nonnote) > && ! sched_insns_conditions_mutex_p (insn, prev_nonnote)) > add_dependence (insn, prev_nonnote, REG_DEP_ANTI); > > Why does it end up with a label at the assertion failure point? > > Alexander Because code label is not a note or debug insn. I think it is impossible to detect such inconsistency in chain_to_prev_insn. If the prev_nonnote is not a code label, the bug will not be exposed this time. Suppose some other optimizations insert a real insn before the jump marked as SCHED_GROUP_P, following scheduler pass will schedule them together silently. That is why I think it is necessary to cleanup SCHED_GROUP_P when a scheduling pass is finished. Thanks, Wei.
