https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82447
--- Comment #7 from amker at gcc dot gnu.org ---
So with necessary IV candidates added, current cost computation has tie between
address candidate and counting down candidate. The tie is introduced because
counting down candidate requires invariant expression (thus increased cost by
1); and it is preferred in determine_group_iv_cost_cond (by decreasing cost by
1). From experience, penalizing invariant expressions in address type IV_USE
is generally better in large cases. we may be able to break tie with below
trivial change:
/* When the condition is a comparison of the candidate IV against
zero, prefer this IV.
TODO: The constant that we're subtracting from the cost should
be target-dependent. This information should be added to the
target costs for each backend. */
if (!elim_cost.infinite_cost_p () /* Do not try to decrease infinite! */
&& integer_zerop (*bound_cst)
&& (operand_equal_p (*control_var, cand->var_after, 0)
|| operand_equal_p (*control_var, cand->var_before, 0)))
- elim_cost -= 1;
+ elim_cost -= 2;
It breaks the tie while doesn't change behavior in large case which has
multiple address type IV_USEs so preference of counting down IV cand can be
cancelled.
