[jdk16] RFR: 8260709: C2: assert(false) failed: unscheduable graph
Roland Westrelin
roland at openjdk.java.net
Wed Feb 3 11:55:51 UTC 2021
On Wed, 3 Feb 2021 08:25:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:
>> The v = field load in the test case is found anti-dependent with the
>> memory phi that merges the exception state of the 2 array
>> allocation. Since JDK-8258393, anti-dependence computation only
>> considers the Phi inputs that are reachable from the memory input of a
>> load. As a consequence, the late control for the load is the control
>> projection of the array allocation in the loop. When loop opts run,
>> PhaseIdealLoop::split_if_with_blocks_post() finds that the load's late
>> control is different from its current control (which is inside the
>> outer loop). It tries to sink the load out of loop but ends up pinning
>> it at its late control, the projection of the second AllocateNode.
>>
>> The logic that expands the AllocateNode doesn't expect a pinned node
>> on the control projection and the result is a broken graph. I think
>> the fix for this would be to clone the load along both the exception
>> and the fallthrough paths. But as noted in JDK-8252372, the whole
>> process of sinking loads out of loops doesn't seem to work as expected
>> (for instance in this case it sinks the load from the outer loop into
>> the inner loop). So instead of going with a complicated fix, I propose
>> simply to detect this corner and that no attempt be made to sink the
>> load. Note that the current logic computes the late control for the
>> load (which should be in the loop), will create a clone for each use
>> and assign the dom_lca of the use's control and the load late control
>> to that use, that is the load late control. So all uses end up at the
>> same location, the load late control. So to detect that case, it's
>> sufficient to test the load late control.
>
> This looks reasonable to me as a point fix for JDK 16, given the plan is to rework that code for JDK 17 with [JDK-8252372](https://bugs.openjdk.java.net/browse/JDK-8252372).
thanks for the reviews @TobiHartmann @chhagedorn
-------------
PR: https://git.openjdk.java.net/jdk16/pull/144
More information about the hotspot-compiler-dev
mailing list