RFR: 8302459: Missing late inline cleanup causes compiler/vectorapi/VectorLogicalOpIdentityTest.java IR failure [v4]
Vladimir Ivanov
vlivanov at openjdk.org
Fri Mar 7 19:26:06 UTC 2025
On Fri, 7 Mar 2025 14:24:11 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:
>> # Issue
>>
>> The `compiler/vectorapi/VectorLogicalOpIdentityTest.java` has been failing because C2 compiling the test `testAndMaskSameValue1` expects to have 1 `AndV` nodes but it has none.
>>
>> # Cause
>>
>> The issue has to do with the criteria that trigger a cleanup when performing late inlining. In the failing test, when the compiler tries to inline a `jdk.internal.vm.vector.VectorSupport::binaryOp` call, it fails because its argument is of the wrong type, mainly because some cast nodes “hide” the more “precise” type.
>> The graph that leads to the issue looks like this:
>> 
>> The compiler tries to inline `jdk.internal.vm.vector.VectorSupport::load` and it succeeds:
>> 
>> The node `3027 VectorBox` has type `IntMaxVector`. `912 CastPP` and `934 CheckCastPP` have type `IntVector`instead.
>> The compiler then tries to inline one of the 2 `bynaryOp` calls but it fails because it needs an argument of type `IntMaxVector` and the argument it is given, which is node `934 CheckCastPP` , has type `IntVector`.
>>
>> This would not happen if between the 2 inlining attempts a _cleanup_ was triggered. IGVN would run and the 2 nodes `912 CastPP` and `934 CheckCastPP` would be folded away. `binaryOp` could then be inlined since the types would match.
>>
>> # Solution
>>
>> Instead of fixing this specific case we try a more generic approach: when late inlining we keep track of failed intrinsics and re-examine them during IGVN. If the `Ideal` method for their call node is called, we reschedule the intrinsic attempt for that call.
>>
>> # Testing
>>
>> Additional test runs with `-XX:-TieredCompilation` are added to `VectorLogicalOpIdentityTest.java` and `VectorGatherMaskFoldingTest.java` as regression tests and `-XX:+IncrementalInlineForceCleanup` is removed from `VectorGatherMaskFoldingTest.java` (previously added as workaround for this issue)
>>
>> Tests: Tier 1-4 (windows-x64, linux-x64/aarch64, and macosx-x64/aarch64; release and debug mode)
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>
> JDK-8302459: create method to prepend and reset generator
src/hotspot/share/opto/callnode.cpp line 1072:
> 1070: #endif
> 1071:
> 1072: void CallJavaNode::prepend_and_reset_generator(PhaseGVN* phase, CallGenerator* cg) {
`prepend_and_reset_generator` sounds way too verbose. Maybe `register_for_late_inline` instead?
Also, `CallGenertaor* cg` argument is redundant. And `phase` is used just to extract `Compile*`.
Either
void CallJavaNode::register_for_late_inline(Compile* C) {
if (generator() != nullptr) {
C->prepend_late_inline(generator());
set_generator(nullptr);
} else {
assert(false, "repeated attempt");
}
}
Or even drop `Compile* C` and use `Compile::current()`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21682#discussion_r1985576552
More information about the hotspot-compiler-dev
mailing list