RFR: 8336702: C2 compilation fails with "all memory state should have been processed" assert [v2]
Roland Westrelin
roland at openjdk.org
Wed Oct 9 07:19:00 UTC 2024
On Tue, 1 Oct 2024 13:22:23 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>> When converting a `LongCountedLoop` into a loop nest, c2 needs jvm
>> state to add predicates to the inner loop. For that, it peels an
>> iteration of the loop and uses the state of the safepoint at the end
>> of the loop. That's only legal if there's no side effect between the
>> safepoint and the backedge that goes back into the loop. The assert
>> failure here happens in code that checks that.
>>
>> That code compares the memory states at the safepoint and at the
>> backedge. If they are the same then there's no side effect. To check
>> consistency, the `MergeMem` at the safepoint is cloned. As the logic
>> iterates over the backedge state, it clears every component of the
>> state it encounters from the `MergeMem`. Once done, the cloned
>> `MergeMem` should be "empty". In the case of this failure, no side
>> effect is found but the cloned `MergeMem` is not empty. That happens
>> because of EA: it adds edges to the `MergeMem` at the safepoint that
>> it doesn't add to the backedge `Phis`.
>>
>> So it's the verification code that fails and I propose dealing with
>> this by ignoring memory state added by EA in the verification 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:
>
> - Merge branch 'master' into JDK-8336702
> - test indentation
> - fix & test
Anyone else for a review?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21009#issuecomment-2401525131
More information about the hotspot-compiler-dev
mailing list