RFR: 8256730: Code that uses Object.checkIndex() range checks doesn't optimize well [v2]

[Roberto Castañeda Lozano]

On Fri, 20 Nov 2020 13:35:24 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This was reported by Paul with the vector API. There are 2 issues:
>> 
>> - CastII nodes (added by Objects.checkIndex()) gets in the way of the
>>   pattern matching performed by range check elimination
>> 
>> - By transforming (CastII (AddI x y)) into (AddI (CastII x) (CastII y))
>>   some CastII can be eliminated which improves address computation code.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - build fix
>  - Merge branch 'master' into JDK-8256730
>  - step over CastII in range checks & push CastII thru add

src/hotspot/share/opto/castnode.cpp line 269:

> 267:                               _carry_dependency, _range_check_dependency);
> 268:     cx->set_req(0, in(0));
> 269:     cx = phase->transform(cx);

Hi Roland, have you tested that these calls to `transform()` do not create an explosion of recursive `Ideal()` calls in the face of long AddI chains (see https://github.com/openjdk/jdk/pull/727).

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

PR: https://git.openjdk.java.net/jdk/pull/1342