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