This is the mail archive of the
mailing list for the GCC project.
Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- From: Jeff Law <law at redhat dot com>
- To: Wei Mi <wmi at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Alexander Monakov <amonakov at ispras dot ru>, 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 11:36:04 -0700
- 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 11/24/13 00:30, Wei Mi wrote:
I think this is showing up because this is the first time we have used
SCHED_GROUP_P in cases where we merely want to keep two instructions
consecutive vs cases where we are required to keep certain instructions
consecutive. For example, all the RTL passes already know they need to
keep a cc0 setter and cc0 user consecutive on a HAVE_cc0 target.
Sorry about the problem.
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.
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 am thinking other cases setting SCHED_GROUP_P should have the same
problem because SCHED_GROUP_P is not cleaned up after scheduling is
done. The flag may become inconsistent after some optimizations and
may cause problem if it is used by later scheduling passes. I don't
know why similar problem was never exposed before.
The fix is to simply cleanup SCHED_GROUP_P flag in sched_finish.
In the latter case passes should already be doing what is necessary to
keep those instructions consecutive. In the former case, we'd have to
audit & fix passes to honor the desire to keep certain instructions
I'll note you're doing an extra pass over all the RTL here. Is there
any clean way you can clean SCHED_GROUP_P without that extra pass over
the RTL? Perhaps when the group actually gets scheduled?
bootstrap is ok. regression test is going on. Is it ok if regression passes?
2013-11-23 Wei Mi <email@example.com>
* haifa-sched.c (cleanup_sched_group): New function.
(sched_finish): Call cleanup_sched_group to cleanup SCHED_GROUP_P.
2013-11-23 Wei Mi <firstname.lastname@example.org>
* testsuite/gcc.dg/pr59020.c (void f):