This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.5] Find more autoinc addressing for induction variables
Hi,
this looks OK; see the questions and suggestions below, though.
> /* Allocates the data structure mapping the (use, candidate) pairs to costs.
> If consider_all_candidates is true, we use a two-dimensional array, otherwise
> we allocate a simple list to every use. */
> @@ -2474,7 +2464,8 @@ infinite_cost_p (comp_cost cost)
> static void
> set_use_iv_cost (struct ivopts_data *data,
> struct iv_use *use, struct iv_cand *cand,
> - comp_cost cost, bitmap depends_on, tree value)
> + comp_cost cost, bitmap depends_on, tree value,
> + bool can_autoinc)
Update the comment describing the new argument.
> + MAY_AUTOINC is set to true if the autoincrement (increasing index by
> + size of MEM_MODE / RATIO) is available. To make this determination, we
> + look at the size of the increment to be made, which is given in CSTEP.
> + CSTEP may be zero if the step is unknown.
> + STMT_AFTER_INC is true iff the statement we're looking at is after the
> + increment of the original biv.
STMT_AFTER_INC seems to be always false (it is false for the IP_AT_USE
candidate for the appropriate use, add_autoinc_candidates ensures that
ainc_use is before the increment for IP_ORIGINAL candidates (why?), and
it is irrelevant otherwise). Is that intentional?
> - if (cost.cost > target_spill_cost [speed])
> + if (cost.cost > (int)target_spill_cost [speed])
> cost.cost = target_spill_cost [speed];
add a space after (int)
> +/* Examine all the use/candidate pairs to see if we find autoincrement
> + opportunities, and create new IP_AT_USE candidates as appropriate.
> + Also, examine IP_ORIGINAL candidates to see if they are incremented
> + next to a use that allows autoincrement, and set their AINC_USE if
> + possible. */
> +
> +static void
> +add_autoinc_candidates (struct ivopts_data *data)
> +{
> + unsigned i, j;
> + struct iv_cand *cand;
> + struct loop *loop = data->current_loop;
> +
> + for (i = 0; i < n_iv_uses (data); i++)
> + {
> + struct iv_use *use = iv_use (data, i);
> + basic_block use_bb = gimple_bb (use->stmt);
> +
> + if (use->type != USE_ADDRESS
> + /* If we insert the increment in any position other than the standard
> + ones, we must ensure that it is incremented once per iteration.
> + It must not be in an inner nested loop, or one side of an if
> + statement. This is ensured by the following two conditions. */
> + || use_bb->loop_father != loop
> + || !dominated_by_p (CDI_DOMINATORS, loop->latch, use_bb)
> + || stmt_could_throw_p (use->stmt))
> + continue;
> +
> + if (data->consider_all_candidates)
> + {
> + for (j = 0; j < n_iv_cands (data); j++)
> + {
> + cand = iv_cand (data, j);
> + maybe_allocate_autoinc_cand (data, use, cand);
> + }
> + }
> + else
> + {
> + bitmap_iterator bi;
> +
> + EXECUTE_IF_SET_IN_BITMAP (use->related_cands, 0, j, bi)
> + {
> + cand = iv_cand (data, j);
> + maybe_allocate_autoinc_cand (data, use, cand);
> + }
> + }
> + }
This requires more explanation -- why do you need to consider other
candidates, instead of creating a single candidate based on the use?
> + renumber_gimple_stmt_uids ();
It might be better to run the renumbering only for the statements in the
current loop, to avoid quadratic behavior for functions with many loops.
Zdenek