RFR: 8350177: C2 SuperWord: Integer.numberOfLeadingZeros, numberOfTrailingZeros, reverse and bitCount have input types wrongly turncated for byte and short [v6]

[Emanuel Peter]

On Wed, 25 Jun 2025 05:56:22 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> Hi all,
>> This patch fixes cases in SuperWord when compiling subword types where vectorized code would be given a narrower type than expected, leading to miscompilation due to truncation. This fix is a generalization of the same fix applied for `Integer.reverseBytes` in [JDK-8305324](https://bugs.openjdk.org/browse/JDK-8305324). The patch introduces a check for nodes that are known to tolerate truncation, so that any future cases of subword truncation will avoid creating miscompiled code.
>> 
>> The patch reuses the existing logic to set the type of the vectors to int, which currently disables vectorization for the affected patterns entirely. Once [JDK-8342095](https://bugs.openjdk.org/browse/JDK-8342095) is merged and automatic casting support is added the autovectorizer should automatically insert casts to and from int, maintaining correctness.
>> 
>> I've added an IR test that checks for correctly compiled outputs. Thoughts and reviews would be appreciated!
>
> Jasmine Karthikeyan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more nodes to the non-truncating list

src/hotspot/share/opto/superword.cpp line 2552:

> 2550:     switch (opc) {
> 2551:     case Op_ExtractS:
> 2552:     case Op_ExtractC:

Are there any tests for these somewhere?

src/hotspot/share/opto/superword.cpp line 2600:

> 2598:   case Op_XorReductionV:
> 2599:   case Op_MaxReductionV:
> 2600:   case Op_MinReductionV:

Why do these vector nodes even end up here? Is that expected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25440#discussion_r2165925142
PR Review Comment: https://git.openjdk.org/jdk/pull/25440#discussion_r2165924451