RFR: 8327963: [Umbrella] Incorrect result of C2 compiled code since JDK-8237581 [v2]

[Roland Westrelin]

> An `Initialize` node for an `Allocate` node is created with a memory
> `Proj` of adr type raw memory. In order for stores to be captured, the
> memory state out of the allocation is a `MergeMem` with slices for the
> various object fields/array element set to the raw memory `Proj` of
> the `Initialize` node. If `Phi`s need to be created during later
> transformations from this memory state, The `Phi` for a particular
> slice gets its adr type from the type of the `Proj` which is raw
> memory. If during macro expansion, the `Allocate` is found to have no
> use and so can be removed, the `Proj` out of the `Initialize` is
> replaced by the memory state on input to the `Allocate`. A `Phi` for
> some slice for a field of an object will end up with the raw memory
> state on input to the `Allocate` node. As a result, memory state at
> the `Phi` is incorrect and incorrect execution can happen.
> 
> The fix I propose is, rather than have a single `Proj` for the memory
> state out of the `Initialize` with adr type raw memory, to use one
> `Proj` per slice added to the memory state after the `Initalize`. Each
> of the `Proj` should return the right adr type for its slice. For that
> I propose having a new type of `Proj`: `NarrowMemProj` that captures
> the right adr type.
> 
> Logic for the construction of the `Allocate`/`Initialize` subgraph is
> tweaked so the right adr type captured in is own `NarrowMemProj` is
> added to the memory sugraph. Code that removes an allocation or moves
> it also has to be changed so it correctly takes the multiple memory
> projections out of the `Initialize` node into account.
> 
> One tricky issue is that when EA split types for a scalar replaceable
> `Allocate` node:
> 
> 1- the adr type captured in the `NarrowMemProj` becomes out of sync
>   with the type of the slices for the allocation
>   
> 2- before EA, the memory state for one particular field out of the
>   `Initialize` node can be used for a `Store` to the just allocated
>   object or some other. So we can have a chain of `Store`s, some to
>   the newly allocated object, some to some other objects, all of them
>   using the state of `NarrowMemProj` out of the `Initialize`. After
>   split unique types, the `NarrowMemProj` is for the slice of a
>   particular allocation. So `Store`s to some other objects shouldn't
>   use that memory state but the memory state before the `Allocate`.
>   
> For that, I added logic to update the adr type of `NarrowMemProj`
> during split unique types and update the memory input of `Store`s that
> don't depend on the memory state ...

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  TestIterativeEA fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24570/files
  - new: https://git.openjdk.org/jdk/pull/24570/files/71fd8315..a4031f3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24570&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24570&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24570/head:pull/24570

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