[PATCH] Change IVOPTS and strength reduction to use expmed cost model

[Richard Henderson]

On 07/25/2012 09:13 AM, William J. Schmidt wrote:
> Per Richard Henderson's suggestion
> (http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01370.html), this patch
> changes the IVOPTS and straight-line strength reduction passes to make
> use of data computed by init_expmed.  This required adding a new
> convert_cost array in expmed to store the costs of converting between
> various scalar integer modes, and exposing expmed's multiplication hash
> table for external use (new function mult_by_coeff_cost).  Richard H,
> I'd appreciate it if you could look at what I did there and make sure
> it's correct.  Thanks!

Correctness looks good.

> I decided it wasn't worth distinguishing between reg-reg add costs and
> reg-constant add costs, so I simplified the strength reduction
> calculations rather than adding another array to expmed for this
> purpose.  But I can make this distinction if that's preferable.

I don't think this is worth thinking about at this level.  This is
something that some rtl-level optimization ought to be able to fix
up trivially, e.g. cse.

> Index: gcc/expmed.h
> ===================================================================
> --- gcc/expmed.h	(revision 189845)
> +++ gcc/expmed.h	(working copy)
> @@ -155,6 +155,11 @@ struct target_expmed {
>    int x_udiv_cost[2][NUM_MACHINE_MODES];
>    int x_mul_widen_cost[2][NUM_MACHINE_MODES];
>    int x_mul_highpart_cost[2][NUM_MACHINE_MODES];
> +
> +  /* Conversion costs are only defined between two scalar integer modes
> +     of different sizes.  The first machine mode is the destination mode,
> +     and the second is the source mode.  */
> +  int x_convert_cost[2][NUM_MACHINE_MODES][NUM_MACHINE_MODES];
>  };

2 * NUM_MACHINE_MODES is quite large...  I think we could do better with

#define NUM_MODE_INT (MAX_MODE_INT - MIN_MODE_INT + 1)

  x_convert_cost[2][NUM_MODE_INT][NUM_MODE_INT];

though really that could be done with all of these fields all at once.

That does suggest it would be better to leave at least inline functions
to access these elements, rather than open code the array access.


r~