This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Wei Mi <wmi at google dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Jeff Law <law at redhat dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Mon, 25 Nov 2013 14:08:24 +0400 (MSK)
- Subject: Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- Authentication-results: sourceware.org; auth=none
- References: <CA+4CFy7TCbnm3irCTKYuQmsz_xPNbC3YmugHC6fjiewPcREzZA at mail dot gmail dot com> <CAMe9rOqLzrsxkfbSLqT29cntdJ_8PURh2NRmoLzQKM5Fzv8BEQ at mail dot gmail dot com> <20130924212516 dot GA11364 at kam dot mff dot cuni dot cz> <CA+4CFy6JTOSgOWwk+cySMaopg+qxcMn=A=L-MQoYK4MVb5FkAg at mail dot gmail dot com> <CA+4CFy6vGb__5DiT+jjYSSCpPCg0a+z2ueqg=0OQA9=E0=WrLw at mail dot gmail dot com> <525DA6FF dot 5010901 at redhat dot com> <CA+4CFy5qXcZz4CVshVjk8AwEu=B-Spctag+KSo+Ue5pgAvxR8Q at mail dot gmail dot com> <525EF180 dot 4020708 at redhat dot com> <CA+4CFy4CuW=U=GDYipxRjtBdszHqxaS_pK4NeJKeNWT+W75Veg at mail dot gmail dot com> <CA+4CFy5K--mRx6k_+Aro8-_ENp+ye3=7PqZQQ4ph6m7MpxW9JA at mail dot gmail dot com> <20131104011801 dot GB32134 at atrey dot karlin dot mff dot cuni dot cz> <CA+4CFy6j-sRhUBTpBOZ=50mnESiYBDG64FiC-71ybDYVyFpC7Q at mail dot gmail dot com> <CAMe9rOqdWFmiqEOrpRJT_YiyvvGmQx-M4qGACMEvV6khyMyc3A at mail dot gmail dot com> <CA+4CFy74eA6arbvph8G1zMAXzDURx_E4NbRdeQXkbRLsOHnvRg at mail dot gmail dot com>
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?
> 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