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?
Many thanks,
Fred
