RFR: 8350896: Integer/Long.compress gets wrong type from CompressBitsNode::Value [v11]
Emanuel Peter
epeter at openjdk.org
Fri Jul 11 13:49:48 UTC 2025
On Fri, 11 Jul 2025 13:30:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:
>> Hi All,
>>
>> This bugfix patch fixes incorrect value computation for Integer/Long. compress APIs.
>>
>> Problems occur with a constant input and variable mask where the input's value is equal to the lower bound of the mask value., In this case, an erroneous value range estimation results in a constant value. Existing value routine first attempts to constant fold the compression operation if both input and compression mask are constant values; otherwise, it attempts to constrain the value range of result based on the upper and lower bounds of mask type.
>>
>> New IR test covers the issue reported in the bug report along with a case for value range based logic pruning.
>>
>> Kindly review and share your feedback.
>>
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>
> Update test
@jatin-bhateja Thanks for the updates! I'm going on vacation, so someone else will have to review this. I'll ping some people.
test/hotspot/jtreg/compiler/c2/gvn/TestBitCompressValueTransform.java line 366:
> 364: res += 800;
> 365: }
> 366: return res;
Can you please use powers-of-2 instead? That way it cannot happen that one error masks out another.
Imagine somehow we should only add `300` (I3), but instead add `100 + 200` (I1 and I2).
-------------
PR Review: https://git.openjdk.org/jdk/pull/23947#pullrequestreview-3010398830
PR Review Comment: https://git.openjdk.org/jdk/pull/23947#discussion_r2200792513
More information about the hotspot-compiler-dev
mailing list