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

[Quan Anh Mai]

On Thu, 26 Feb 2026 17:22:00 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/rangeinference.hpp line 417:
> 
>> 415:   static CTP infer_lshift(CTP t1, int shift) {
>> 416:     constexpr int type_bits = sizeof(U<CTP>) * 8;
>> 417:     int masked_shift = shift & (type_bits - 1);
> 
> Sadly, `sizeof` does not work for `intn_t`, you may need to count the set bits of the maximum unsigned value.

It is great if you can add a utility in `intn_t.hpp` that will return a correct bit size at least for the unsigned types `uintn_t`, `juint`, `julong`.

> src/hotspot/share/opto/rangeinference.hpp line 430:
> 
>> 428:     S<CTP> shi = s_overflow ? std::numeric_limits<S<CTP>>::max() : shifted_shi;
>> 429: 
>> 430:     U<CTP> shifted_ulo = t1->_ulo << masked_shift;
> 
> I believe unsigned bounds still hold when overflowing, so you don't need to check for the overflow of unsigned bounds.

No, I am mistaken, please ignore this. An example for `int4_t` is `0b0001 <= 0b1000` but it is not the case that `(0b0001 << 1) <= (0b1000 << 1)`

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

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