RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8]

[Emanuel Peter]

On Tue, 2 Dec 2025 15:14:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Merge branch 'master' into JDK-8354282
>>  - whitespace
>>  - review
>>  - review
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/opto/castnode.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - review
>>  - review
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5
>
> src/hotspot/share/opto/castnode.hpp line 108:
> 
>> 106:     // Floating: The Cast is only dependent on the single range check.
>> 107:     // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely
>> 108:     //            remove the cast because the array access will be safe.
> 
> The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right?
> So is it not therefore already pinned?
> 
> Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization?

Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581642290