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

[Jatin Bhateja]

On Mon, 5 May 2025 06:49:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @eme64 , I have addressed and responded to your comments, please verify.
>
>> @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();
>>       hi = result_bit_width < mask_bit_width ? (1L << result_bit_width) - 1 : hi;
>> ```
>> 
>> Can you please explain it with an example, and walk me through the steps to the incorrect constant folding?
> 
> Let's assume the following
>  - The input was a constant value Integer.MIN_VALUE, hence ideal type TypeInt will have both _lo and _hi set to MIN_VALUE,
>  - Currently, _lo value of result value range flip b/w 0 or MIN_VALUE,  lets take that to be MIN_VALUE in our case.
> 
> Earlier _hi value of the result value range was set to _hi value of the source value range.
> 
> `      hi = mask_max_bw < max_bw ? (1L << mask_max_bw) - 1 : src_type->hi_as_long();
> `
> 
> If the result bit width was less than the maximum bit width of the integral type, in that case both _hi and _lo values were being set to MIN_VALUE resulting into a constant value.

> @jatin-bhateja Thanks for explaining the case with `MIN_VALUE`. I suppose the same could happen if `lo = 0` and `src_type->_hi = 0`?
> 

This patch handles constant folding of ZERO value upfront during ::Value transforms, we only land here to constrain the value range. **Glad you are picking up value range-based optimization**, these are tricky ones, and **that is why we need a more robust infrastructure like KnowBits**, which makes the job easy. Let me tune this check and update the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/23947#issuecomment-2850543682