On Tue, 10 May 2011, Bernd Schmidt wrote:
> The scheduler knows that insns with different COND_EXEC conditions don't
> conflict and can be scheduled independently. Unfortunately, sched-deps.c
> does not try to keep the conditions valid as it progresses. For example,
>
> [B0] A0 = [A1]
> B0 = something
> [!B0] [A2] = A0
>
> The first and third insns have opposite conditions, so the scheduler
> decides they are independent. For most targets this isn't a problem, as
> the insn in the middle will produce enough dependencies to ensure the
> right order. However, on C6X, order alone isn't sufficient due to the
> exposed pipeline: we also need to ensure that the latencies are observed.
>
> @@ -2871,6 +2895,21 @@ sched_analyze_insn (struct deps_desc *de
> }
> }
>
> + INIT_REG_SET (&set_or_clobbered);
> + bitmap_ior (&set_or_clobbered, reg_pending_clobbers, reg_pending_sets);
> + EXECUTE_IF_SET_IN_REG_SET (&set_or_clobbered, 0, i, rsi)
> + {
> + struct deps_reg *reg_last = &deps->reg_last[i];
> + rtx list;
> + for (list = reg_last->uses; list; list = XEXP (list, 1))
> + {
> + rtx other = XEXP (list, 0);
> + if (INSN_COND (other) != const_true_rtx
> + && refers_to_regno_p (i, i + 1, INSN_COND (other), NULL))
> + INSN_COND (other) = const_true_rtx;
> + }
> + }
> +
> /* If the current insn is conditional, we can't free any
> of the lists. */
> if (sched_has_condition_p (insn))
Could the above be conditional on whether the target CPU is exposed-pipeline?
I'm concerned this may degrade scheduling for other targets in some cases.
I wonder if sharing predicate RTXes between setters and users could also be a
solution. I even thought (until moments ago) GCC was already doing that, but
apparently I was mistaken, ifcvt.c explicitly does copy_rtx.
Thanks.
Alexander
