Re: [PR middle-end/81931] do not pass 0 precision in get_nonzero_bits

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

On Thu, Aug 24, 2017 at 8:59 AM, Marc Glisse <marc.glisse@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