On Thu, Aug 24, 2017 at 8:59 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Thu, 24 Aug 2017, Aldy Hernandez wrote:
>
>> As discussed in the PR...
>>
>> CCP is passing a precision of 0 to get_nonzero_bits for complex
>> numbers. With my last wide_int sign extension patch, the sign
>> extension of -1 with a precision of 0 returns 0, whereas it previously
>> was preturning all ones. The attached patch calls element_precision,
>> to avoid getting a precision of 0.
>
>
> So if we call get_nonzero_bits on a complex number, we get -1 with the
> precision of the real part? Not sure that's very meaningful :-/ What do the
> callers (with complex_type) look like, do they check if this returns -1 and
> give up in that case?
>
> + /* Use element_precision instead of TYPE_PRECISION so complex and
> + vector types get a non-zero precision. */
>
> IIRC, on vectors, TYPE_PRECISION gives the number of elements. Still, better
> not rely on that indeed.
Yeah, I guess the fallback in
if (!ri)
return wi::shwi (-1, precision);
should in the end use a precision that matches the size of the type
if it is not INTEGRAL_TYPE_P. OTOH that may run into
MAX_BITSIZE_MODE_ANY_INT limitations... (AVX512 vector types).
I guess the cleanest approach would be to disallow get_nonzero_bits
on sth non-integral but it could in theory make sense on vectors or
floats.
Anyway, the proposed patch improves the situation (vector types
already get a non-zero precision as TYPE_PRECISION is mapped
to TYPE_VECTOR_SUBPARTS there).
So -- ok for trunk.
Thanks,
Richard.
> + unsigned int precision = element_precision (TREE_TYPE (name));
>
> TREE_TYPE is not necessary there (it doesn't hurt though).
>
> --
> Marc Glisse
