RFR: 8291669: [REDO] Fix array range check hoisting for some scaled loop iv [v3]

[Tobias Hartmann]

On Fri, 9 Sep 2022 03:31:31 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> src/hotspot/share/opto/loopTransform.cpp line 2776:
>> 
>>> 2774:         // This logic is shared by int and long. For int, the result may overflow
>>> 2775:         // as we use jlong to compute so do the check here. Long result may also
>>> 2776:         // overflow but that's fine because result wraps.
>> 
>> But doesn't this mean that we bail out for integer overflows while not bailing out for long overflows?
>
> Yes, it does. If this inconsistency doesn't look good, I could also try adding long overflow checks just like what we have in utility function `bool add_overflows(T x, T y)`.

I'm just wondering if there's a good reason for bailing out for integer overflows and if the same applies to long overflows. @rwestrel, you added that check with JDK-8278296, do you remember why?

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

PR: https://git.openjdk.org/jdk/pull/9851