RFR: 8297264: C2: Cast node is not processed again in CCP and keeps a wrong too narrow type which is later replaced by top [v2]
Christian Hagedorn
chagedorn at openjdk.org
Thu Dec 1 14:40:53 UTC 2022
> 
>
> During CCP, we optimize the type of `348 CastII` in `CastIINode::Value()`: It matches the `CmpI/If` pattern because the current type of `119 Phi` is a constant int:
> https://github.com/openjdk/jdk/blob/9f24a6f43c6a5e1fa92275e0a87af4f1f0603ba3/src/hotspot/share/opto/castnode.cpp#L213-L215
>
> Later in CCP, the type of `119 Phi` is updated and is no longer a constant but `348 CastII` is not processed anymore during CCP and keeps its wrong too narrow type. We apply more loop opts and at some point, the `CastII` is replaced by top because the input type is outside of the wrong type range of the `CastII`. Some data nodes are folded and the graph is left in a broken state and we assert during GCM.
>
> I propose to add a `CastII` node back to the CCP worklist if we find such a `Cmp/If` pattern to ensure that the `CastII` type is correctly set during CCP.
>
> Thanks,
> Christian
Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
Update test/hotspot/jtreg/compiler/c2/TestCastIIWrongTypeCCP.java
Co-authored-by: Roberto Castañeda Lozano <robcasloz at users.noreply.github.com>
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/11448/files
- new: https://git.openjdk.org/jdk/pull/11448/files/79e13192..6064af50
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=11448&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=11448&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/11448.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/11448/head:pull/11448
PR: https://git.openjdk.org/jdk/pull/11448
More information about the hotspot-compiler-dev
mailing list