RFR: 8349637: Integer.numberOfLeadingZeros outputs incorrectly in certain cases [v3]

[Jasmine Karthikeyan]

On Fri, 14 Feb 2025 15:13:43 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Thank you for fixing this. More broadly we should double check the intrinsics of Long/Integer.numberOfLeading/Trailing/Zeros (we added in the integration of Integration of JEP 426: Vector API) and follow up with any necessary tests and/or fixes in subsequent PRs.
>
> @PaulSandoz @jatin-bhateja This should really have been caught by VectorAPI testing, but apparently not the whole range was covered.

@eme64 Thanks for the detailed analysis! I just checked the Vector API, and I believe it's not affected. I think the issue is that we have conflicting semantics for leading zeros with autovectorization and the Vector API, since `Integer.numberOfLeadingZeros((byte)1) == 31`, but `ByteVector.broadcast(ByteVector.SPECIES_256, 1).lanewise(VectorOperators.LEADING_ZEROS_COUNT) == 7`. I think it shouldn't be too hard to adapt the current logic for autovectorization semantics, we could do something like this:

dst = current_leading_zeros_byte(src);
tmp = src >= 0 ? 24 : 0; // vector blend operation, should be constant 16 for shorts
dst = dst + tmp

But I agree that since this is an entirely different issue it'd be good to do it separately.

@TobiHartmann Thanks a lot for the thorough test, I'll make sure to adapt it and add it to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23579#issuecomment-2659596580