Re: [PATCH] Fix PR49715, (float)unsigned -> (float)signed

[Richard Guenther <rguenther at suse dot de>]

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.