RFR: 8278857: C2: optimize (x << 2) & -4 to x (and similar patterns) -> KnownBits for LShift

[Quan Anh Mai]

On Thu, 26 Feb 2026 17:16:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This PR contains the first of the two changes necessary to resolve
>> JDK-8278857.
>> 
>> The commit message, pasted below, has additional details.
>> 
>>> Augment `RangeInference` with information about left shifts
>>> 
>>> Add `RangeInference::infer_lshift()` to compute type information for
>>> left shift operations.  This method tracks known zero bits in the low
>>> positions (the bottom `shift` bits are always zero after a left shift)
>>> and computes signed and unsigned range bounds when the shift does not
>>> cause overflow.
>>> 
>>> This is the first of the two changes necessary to resolve JDK-8278857.
>>> The second change will build on top of these changes to enable AND nodes
>>> to be optimized away when the bits that would have been cleared by the
>>> AND operation were already known to be zero.
>
> src/hotspot/share/opto/mulnode.cpp line 1148:
> 
>> 1146:   // If the left input is BOTTOM or if nothing is known about the shift amount,
>> 1147:   // then the result is BOTTOM
>> 1148:   if (t2 == TypeInt::INT || t1 == Type::BOTTOM || t2 == Type::BOTTOM) {
> 
> In general, `x << y` is defined to be `x << (y & 31)`. Can you tighten the type of the second operand using `normalized_t2 = RangeInference::infer_and(t2, TypeInt::make(31))`. It may allow you to have a complete picture of the operand here. For example, if `t2` has the lowest 5 bits known, then normalising it results in a constant, or if `normalized_t2->_lo == 10`, then you can infer that the result will have the lowest 10 bits being 0, which is not the case for the non-normalised `t2`.

Of course, being too general in 1 take is not mandatory, so you may start with the cases when `y & 31` being a constant, and leave other cases for future RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29898#discussion_r2860315681