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>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, "H.J. Lu" <hjl dot tools at gmail dot com>, 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: Wed, 16 Oct 2013 14:05:20 -0600
- Subject: Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOo-dc7=ax8_pA21wuxnqphLBvf_Voi2n1OHJX7ZEab=ew at mail dot gmail dot com> <CA+4CFy4fqCRvM2Luw2_p6AEZOmucSV1KemntEO3_XU5TfzA-7A at mail dot gmail dot com> <CA+4CFy6gdxREYiJa2B70RBe2aUtLY3zQ9ShK9jGEy26Hdn9QOg at mail dot gmail dot com> <CAMe9rOp1R8XACsL=v-JZkvpPzTOFiZhZPMqQXWkmPgHW5cjC6w at mail dot gmail dot com> <CA+4CFy5nM2Dw7kv0G61N5PKHoAanmAaKm+45oS4pN22TKgSAFg at mail dot gmail dot com> <20130922095726 dot GA23006 at atrey dot karlin dot mff dot cuni dot cz> <20130922101916 dot GA31130 at atrey dot karlin dot mff dot cuni dot cz> <CA+4CFy5n=rTH+fmndNXLJkJgzLd4uCmucvPf+QfGWNsvhPQ1CQ at mail dot gmail dot com> <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>
On 10/15/13 15:30, Wei Mi wrote:
Can't you just look at the last insn in the block and if it's a
conditional peek at the previous insn and see if it sets CC mode register?
Aren't you just trying to see if we have a comparison feeding the
conditional jump and if they're already adjacent? Do you actually need to
get the condition code regs to do that test?
Yes, I am trying to see if we have a comparison feeding the
conditional jump and if they're already adjacent. Do you have more
easier way to do that test?
Hmm, I guess that's effectively what you're doing, I guess I was just
surprised by the need to first get the fixed_condition_code_regs as I
expected you to just extract them from the conditional jump. But
thinking a bit more about it now your solution seems rather clean.
Go ahead and consider that pre-approved. Just send it to the list with
a note that I approved it in this thread.
static void haifa_init_only_bb (basic_block, basic_block);
diff --git a/gcc/sched-rgn.c b/gcc/sched-rgn.c
index e1a2dce..156359e 100644
@@ -2443,6 +2443,8 @@ add_branch_dependences (rtx head, rtx tail)
cc0 setters remain at the end because they can't be moved away from
their cc0 user.
+ Predecessors of SCHED_GROUP_P instructions at the end remain at the
COND_EXEC insns cannot be moved past a branch (see e.g. PR17808).
Insns setting TARGET_CLASS_LIKELY_SPILLED_P registers (usually
@@ -2465,7 +2467,8 @@ add_branch_dependences (rtx head, rtx tail)
&& sets_likely_spilled (PATTERN (insn)))))
- || NOTE_P (insn))
+ || NOTE_P (insn)
+ || (last != 0 && SCHED_GROUP_P (last)))
if (!NOTE_P (insn))
This looks like a straighforward bugfix and probably should go forward
independent of this enhancement.
Ok, I will separate it into another patch.