This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]