RFR: 8288204: GVN Crash: assert() failed: correct memory chain [v3]

[Yi Yang]

On Tue, 25 Oct 2022 22:29:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> EA may incorrectly processing LoadB#971 when it splits unique memory slice for allocation instance. LoadB#971 memory should not reference Phi with different type and EA should should look through MergeMem nodes when creating unique memory slice. If LoadB#971 is load from different object (or merge of objects). Then It's AddP node should not be change to instance specific one. Would be nice to see this subgraph just after EA.

@vnkozlov  LoadB#971 is not processed by EA, it was expanded by ArrayCopyNode#338(which is processed by EA) in arraycopy_forward:

MergeMem#466
   |
   |
   v
ArrayCopy#337
          |
          v
       Proj#242
          |
          |
          v
ArrayCopy#338 (_src_type/_dest_type has precise types)

https://github.com/openjdk/jdk/blob/78454b69da1434da18193d32813c59126348c9ea/src/hotspot/share/opto/arraycopynode.cpp#L383-L408

mem is Proj#242, mm(`960  MergeMem  === _  1  242  1  1  967  [[]]`) is based on mem,  _src_type and _dest_type are precise types(`byte[int:8]:NotNull:exact+any *,iid=177`) after [JDK-8233164](https://bugs.openjdk.org/browse/JDK-8233164). When generating LoadB#971, we can not find _src_type alias index(32) from mm, so it uses base memory(Proj#242) as its memory input:

242  Proj  ===  337  [[ ... ]] #2  Memory: @BotPTR *+bot, idx=Bot; 
971  LoadB  ===  958  242  969

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

PR: https://git.openjdk.org/jdk/pull/9777