RFR: 8266480: Implicit null check optimization does not update control of hoisted memory operation

[Nils Eliasson]

On Tue, 18 May 2021 13:40:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2 replaces explicit null checks by hoisting a nearby memory operation to the null check and using it as implicit null check. In some cases, control of that memory operation is not updated correctly, leading to assert failures during `PhaseCFG::verify()` because a use is no longer dominated by its definition.
> 
> After matching, the graph looks like this:
> 
> <img src="https://user-images.githubusercontent.com/5312595/118652773-346fc280-b7e7-11eb-828a-eddb72b81d6e.png" width=50% height=50%>
> 
> `64 testP_reg` is an explicit null check and `78 loadD`, `73 storeD` and `77 storeImmI` are candidates for an implicit null check because they are operating on the same oop. `PhaseCFG::implicit_null_check` decides to hoist the `77 storeImmI` from the `not_null_block` B12 to the null check in B11/B13:
> 
> <img src="https://user-images.githubusercontent.com/5312595/118652778-36d21c80-b7e7-11eb-88d0-1c2c117a9450.png" width=50% height=50%>
> 
> Now the problem is that control of `77 storeImmI` was not updated and still points into the non-dominating block B15. The following code is supposed to fix this:
> https://github.com/openjdk/jdk/blob/9d168e25d1e2e8b662dc7aa6cda7516c423cef7d/src/hotspot/share/opto/lcm.cpp#L413-L418
> 
> However, it does not trigger because control is not the `not_null_block->head()` but `59 MachProj` which is the control projection from `60 CallLeafDirect` emitted by a `drem`. The fix is to simply check `get_block_for_node(ctrl)` instead.
> 
> This is an old issue that was only caught by the assert recently introduced by [JDK-8263227](https://bugs.openjdk.java.net/browse/JDK-8263227).
> 
> Thanks,
> Tobias

Does nodes 73, 77 and 78 touch different memory slices? Otherwise 78 should be anti-dependent on 73 and 77.

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

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