RFR: 8350896: Integer/Long.compress gets wrong type from CompressBitsNode::Value [v15]
Jatin Bhateja
jbhateja at openjdk.org
Tue Jul 22 10:28:12 UTC 2025
On Wed, 16 Jul 2025 10:43:34 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:
>
> Refine lower bound computation
src/hotspot/share/opto/intrinsicnode.cpp line 358:
> 356: assert(lo == (bt == T_INT ? min_jint : min_jlong) || lo == 0, "");
> 357:
> 358: if (src_type->hi_as_long() >= 0) {
Inorder to check for non-negative non-constant src_type, check should be against the lower bound i.e. src_type->lo_as_long() >= 0 since C2's integral types (TypeInt/TypeLong) maintains an invariant that _lo > _hi for non-constant values, iff _lo == _hi then it's a singleton value or a constant.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23947#discussion_r2222010818
More information about the hotspot-compiler-dev
mailing list