> Can I please get reviews for this PR? > > The most common and frequent use of NonEscaping Phis merging object > allocations is for debugging information. The two graphs below show numbers > for Renaissance and DaCapo benchmarks - similar results are obtained for all > other applications that I tested. > > With what frequency does each IR node type occurs as an allocation merge > user? I.e., if the same node type uses a Phi N times the counter is > incremented by N: > >  > > What are the most common users of allocation merges? I.e., if the same node > type uses a Phi N times the counter is incremented by 1: > >  > > This PR adds support scalar replacing allocations participating in merges > used as debug information OR as a base for field loads. I plan to create > subsequent PRs to enable scalar replacement of merges used by other node > types (CmpP is next on the list) subsequently. > > The approach I used for _rematerialization_ is pretty straightforward. It > consists basically of the following. 1) New IR node (suggested by V. Kozlov), > named SafePointScalarMergeNode, to represent a set of > SafePointScalarObjectNode; 2) Each scalar replaceable input participating in > a merge will get a SafePointScalarObjectNode like if it weren't part of a > merge. 3) Add a new Class to support the rematerialization of SR objects that > are part of a merge; 4) Patch HotSpot to be able to serialize and deserialize > debug information related to allocation merges; 5) Patch C2 to generate > unique types for SR objects participating in some allocation merges. > > The approach I used for _enabling the scalar replacement of some of the > inputs of the allocation merge_ is also pretty straightforward: call > `MemNode::split_through_phi` to, well, split AddP->Load* through the merge > which will render the Phi useless. > > I tested this with JTREG tests tier 1-4 (Windows, Linux, and Mac) and didn't > see regression. I also experimented with several applications and didn't see > any failure. I also ran tests with "-ea -esa -Xbatch -Xcomp > -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -server > -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions > -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP" and didn't observe any related > failures.
Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Catching up with master Merge remote-tracking branch 'origin/master' into rematerialization-of-merges - Fix tests. Remember previous reducible Phis. - Address PR review 3. Some comments and be able to abort compilation. - Merge with Master - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement method. - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue & create new IR class to represent scalarized merges. - Add support for SR'ing some inputs of merges used for field loads - Fix some typos and do some small refactorings. - Merge master - Add support for rematerializing scalar replaced objects participating in allocation merges ------------- Changes: https://git.openjdk.org/jdk/pull/12897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12897&range=09 Stats: 2253 lines in 26 files changed: 1992 ins; 108 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/12897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12897/head:pull/12897 PR: https://git.openjdk.org/jdk/pull/12897