RFR: 8289943: Simplify some object allocation merges
Cesar Soares
duke at openjdk.org
Thu Jul 7 20:01:34 UTC 2022
On Tue, 7 Jun 2022 23:24:02 GMT, Cesar Soares <duke at openjdk.org> wrote:
> Hi there, can I please get some feedback on this approach to simplify object allocation merges in order to promote Scalar Replacement of the objects involved in the merge?
>
> The basic idea for this [approach was discussed in this thread](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2022-April/055189.html) and it consists of:
> 1) Identify Phi nodes that merge object allocations and replace them with a new IR node called ReducedAllocationMergeNode (RAM node).
> 2) Scalar Replace the incoming allocations to the RAM node.
> 3) Scalar Replace the RAM node itself.
>
> There are a few conditions for doing the replacement of the Phi by a RAM node though - Although I plan to work on removing them in subsequent PRs:
>
> - ~~The original Phi node should be merging Allocate nodes in all inputs.~~
> - The only supported users of the original Phi are AddP->Load, SafePoints/Traps, DecodeN.
>
> These are the critical parts of the implementation and I'd appreciate it very much if you could tell me if what I implemented isn't violating any C2 IR constraints:
>
> - The way I identify/use the memory edges that will be used to find the last stored values to the merged object fields.
> - The way I check if there is an incoming Allocate node to the original Phi node.
> - The way I check if there is no store to the merged objects after they are merged.
>
> Testing:
> - Linux. fastdebug -> hotspot_all, renaissance, dacapo
Hi there, can someone please take a look and let me know if this is going in a reasonable direction?
@vnkozlov - is this more or less on the lines of what you were thinking?
-------------
PR: https://git.openjdk.org/jdk/pull/9073
More information about the hotspot-compiler-dev
mailing list