On Tue, Oct 11, 2016 at 03:29:54PM -0600, Martin Sebor wrote:
> >+signed int vec_cntlz_lsbb (vector signed char);
> >+signed int vec_cntlz_lsbb (vector unsigned char)
> >+
> >+signed int vec_cnttz_lsbb (vector signed char);
> >+signed int vec_cnttz_lsbb (vector unsigned char);
> ...
> >+The @code{vec_cntlz_lsbb} function returns the count of the number of
> >+consecutive leading byte elements (starting from position 0 within the
> >+supplied vector argument) for which the least-significant bit
> >+equals zero. The @code{vec_cnttz_lsbb} function returns the count of
> >+the number of consecutive trailing byte elements (starting from
> >+position 15 and counting backwards within the supplied vector
> >+argument) for which the least-significant bit equals zero.
>
> Since these return a non-negative result I'm wondering if it would
> make more sense to declare them to return unsigned rather a "signed
> int."
We have to do what the ABI says, I'm afraid ;-)
> Alternatively (and I admit I have no idea if this is even
> doable in the back end), since the return value is within a narrow
> range of unsigned integers (between zero and 16, IIUC) would it be
> possible to constrain the range of its return values, like for
> the scalar __builtin_popcount?
The intrinsics expand to RTL code. GCC can usually figure out what
range of values can be produced, except that the UNSPECs don't help
here.
Segher
