Re: expmed.c cost calculation limited to word size

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Mar 26, 2013 at 6:55 PM, Frederic Riss <frederic.riss@gmail.com> wrote:
> While working on having the divisions by constants optimized by my GCC
> targeting, I realized that whatever *muldi3_highpart my backend
> provides, it would never be used because of the bounds checks that
> expmed.c does on the cost arrays. For example:
>
>    choose_multiplier (abs_d, size, size - 1,
>       &mlr, &post_shift, &lgup);
>    ml = (unsigned HOST_WIDE_INT) INTVAL (mlr);
>    if (ml < (unsigned HOST_WIDE_INT) 1 << (size - 1))
>      {
>         rtx t1, t2, t3;
>
> =>    if (post_shift >= BITS_PER_WORD
> =>        || size - 1 >= BITS_PER_WORD)
>           goto fail1;
>
>        extra_cost = (shift_cost[speed][compute_mode][post_shift]
>              + shift_cost[speed][compute_mode][size - 1]
>              + add_cost[speed][compute_mode]);
>
> According to the commit log where these checks where added, they only
> serve as to not overflow the cost arrays bellow. Even though a backend
> is fully capable of DImode shifts and multiplies, they won't be
> considered because of this check. The cost arrays are filled up to
> MAX_BITS_PER_WORD, thus as a temporary workaround I have defined
> MAX_BITS_PER_WORD to 64, and I have softened the checks to fail only
> above MAX_BITS_PER_WORD. This allows my 32bits backend to specify that
> it wants these optimizations to take place for 64bits arithmetic.
>
> What do people think about this approach? does it make sense?

Another approach would be to simply use the cost of a BITS_PER_WORD
shift for bigger shifts.  Adjusting MAX_BITS_PER_WORD sounds like a hack
to me.

Note that on trunk I see the cost arrays are now inline functions, so things
may have changed for the better already.

Richard.

> Many thanks,
> Fred