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