RFR: 8350896: Integer/Long.compress gets wrong type from CompressBitsNode::Value [v5]

[Emanuel Peter]

On Wed, 23 Apr 2025 08:36:50 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:
> 
>   Review comments resoultions

@jatin-bhateja Thanks for the updates!
I think I now understand everything except this, so we are making good progress 😊 

      // For upper bound estimation of result value range with a constant input we
      // pessimistically pick max_int value to prevent incorrect constant folding
      // in case input equals above estimated lower bound.
      hi = src_type->hi_as_long() == lo ? hi : src_type->hi_as_long();


Can you please explain it with an example, and walk me through the steps to the incorrect constant folding?

src/hotspot/share/opto/intrinsicnode.cpp line 299:

> 297:       // pessimistically pick max_int value to prevent incorrect constant folding
> 298:       // in case input equals above estimated lower bound.
> 299:       hi = src_type->hi_as_long() == lo ? hi : src_type->hi_as_long();

I still don't understand this case. Where would the constant folding happen exactly if this was not here?

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

PR Review: https://git.openjdk.org/jdk/pull/23947#pullrequestreview-2786954830
PR Review Comment: https://git.openjdk.org/jdk/pull/23947#discussion_r2055841706