| Message ID | BCD7D45B-CD86-4D0D-B85C-2B3DF6E86DED@comcast.net |
|---|---|
| State | New |
| Headers | show |
On 10/09/2015 11:36 PM, Mike Stump wrote: > So, I keep on seeing inaccurate schedule time on the conditional > branches after a store, and tracked it down to this type of solution. > On my machine, I can run these two in the same cycle, but with a > REG_DEP_OUTPUT dependency it was moving the branch to the next cycle. > I kinda wanted a control dependency of some sort, but those seem only > to be used for predicated instructions, which doesn’t apply to the > case at hand. For the instructions, from my view, there are no data > dependencies at all. What dependencies exists is the dependency that > one cannot interchange: > mem[$r1] = 1 > if ($r2) jump L5 > This last case being the one that I’m interested in. So, the > question is, is the below patch the right way to fix this? I'd recommend trying to fix this with the adjust_cost hook instead. Bernd
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c index 5434831..1f88734 100644 --- a/gcc/sched-deps.c +++ b/gcc/sched-deps.c @@ -3044,7 +3044,7 @@ sched_analyze_insn (struct deps_desc *deps, rtx x, rtx_insn *insn) { if (! sched_insns_conditions_mutex_p (insn, pending->insn ())) add_dependence (insn, pending->insn (), - REG_DEP_OUTPUT); + REG_DEP_ANTI); pending = pending->next (); pending_mem = pending_mem->next (); }
So, I keep on seeing inaccurate schedule time on the conditional branches after a store, and tracked it down to this type of solution. On my machine, I can run these two in the same cycle, but with a REG_DEP_OUTPUT dependency it was moving the branch to the next cycle. Now, I’ll plead ignorance if this is the right way to fix the issue, but thought I would post it for comment. I kinda wanted a control dependency of some sort, but those seem only to be used for predicated instructions, which doesn’t apply to the case at hand. For the instructions, from my view, there are no data dependencies at all. What dependencies exists is the dependency that one cannot interchange: $r1 = 1 jump L5 neither, can one interchange: $r1 = 1 if ($r2) jump L5 nor: mem[$r1] = 1 if ($r2) jump L5 This last case being the one that I’m interested in. So, the question is, is the below patch the right way to fix this? if (dep_type == REG_DEP_ANTI) cost = 0; else if (dep_type == REG_DEP_OUTPUT) { cost = (insn_default_latency (insn) - insn_default_latency (used)); if (cost <= 0) cost = 1; }