On Thu, 21 Jul 2011, Richard Henderson wrote:
> On 07/21/2011 08:09 AM, Richard Guenther wrote:
> > + /* It's not interesting to widen anything smaller than SImode. */
> > + if (TYPE_PRECISION (TREE_TYPE (rhs1)) < GET_MODE_PRECISION (SImode)
> > + || (!TYPE_UNSIGNED (TREE_TYPE (rhs1))
> > + && TYPE_PRECISION (TREE_TYPE (rhs1)) == GET_MODE_PRECISION (SImode)))
> > + return false;
>
> Hard-coding SImode? Really? You might as well hard-code 32. At least
> that's "more correct" when someone does have BITS_PER_UNIT != 8.
I grepped for named expanders and saw mostly floatsi (thus, SImode).
>
> > + /* Try if the value fits in a signed SImode integer, that's the only
> > + interesting case. */
> > + if (!double_int_fits_to_tree_p (intSI_type_node,
> > + tree_to_double_int (vr->min))
> > + || !double_int_fits_to_tree_p (intSI_type_node,
> > + tree_to_double_int (vr->max)))
> > + return false;
>
> unsigned long long -> long long is also a very interesting transform.
Yeah, floatdi would also be interesting, but it appears that RTL
optimizers can at least figure out a testcase like
double func(unsigned long long x)
{
return (x & 0x7fffffffffffffffULL) * 0.01;
}
themselves.
> Indeed, that's the one will help 64-bit targets most. Unsigned SImode
> normally just gets zero-extended to signed DImode. Whereas unsigned
> DImode generally has to do the bias/convert/unbias thing.
Ok, I'll think of some more interesting testcases and handling
DImode.
As of hard-coding SImode I want to avoid truncation to something
smaller than int, so should I rather use ints precision and type
(and then iterate over wider integer modes than the mode of int)?
Thanks,
Richard.
