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

[Emanuel Peter]

On Fri, 14 Feb 2025 15:24:16 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> Shouln't L.6230 read as follows?
>> 
>>   // LZCNT = 31 - (biased_exp - 127)
>
>> Shouln't L.6230 read as follows?
>> 
>> ```
>>   // LZCNT = 31 - (biased_exp - 127)
>> ```
> 
> @rgiulietti I believe you are correct, the comment there is wrong. I think it is a typo, it might be because the intrinsic logic computes `LZCNT = 32 - ((biased_exp - 127) + 1)` which is equivalent. I'll update the comments to make this more clear.

@jaskarth 
> Thanks for the detailed analysis! I just checked the Vector API, and I believe it's not affected.

- For the **floating-issue** of this PR: Vector API **IS AFFECTED**. See my example above.
- For **truncation** issue: Vector API is **NOT** affected. For normal Java uses of `Integer.numberOfLeadingZeros` and `Integer.numberOfTrailingZeros`, we operate explicitly on 32 bits, no matter if the input is byte, short or int. So we must use some 32bit implementation of `CountLeadingZerosV`, no matter if it is on byte, short or int. But the VectorAPI explicitly operates on 8bit bytes, 16bit shorts and 32bit ints, and can use 8bit, 16bit and 32bit variants respectively of `CountLeadingZerosV`.

Note there are other affected operations for the **truncation** issue. `Integer.reverse` is also affected, `Integer.numberOfTrailingZeros` too, and maybe others.

Fix alternatives for the SuperWord **truncation** issue:
- Disable the affected operations in vectorizer (easiest to implement, but possible performance regression)
- Cast to int, do operations in int, cast result back.
- Implement special operations in the backend that know that they are operating with implicit 32 bits, even if the data is byte or short. So that would be 32-8 implicit leading zeros for byte, or 32-16 implicit leading zeros for short.

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

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