RFR: 8325478: Restructure the macro expansion compiler phase to not include macro elimination [v2]

[Daniel Lundén]

On Wed, 11 Jun 2025 09:48:19 GMT, Saranya Natarajan <snatarajan at openjdk.org> wrote:

>> This changeset restructures the macro expansion phase to not include macro elimination and also adds a flag StressMacroElimination which randomizes macro elimination ordering for stress testing purposes.
>> 
>> Changes:
>> - Implemented a method `eliminate_opaque_looplimit_macro_nodes` that removes the functionality for eliminating Opaque and LoopLimit nodes from the `expand_macro_nodes ` method. 
>> - Introduced compiler phases` PHASE_AFTER_MACRO_ELIMINATION` 
>> -  Added a new Ideal phase for individual macro elimination steps. 
>> - Implemented the flag `StressMacroElimination`. Added functionality tests for `StressMacroElimination`, similar to previous stress flag `StressMacroExpansion` ([JDK-8317349](https://bugs.openjdk.org/browse/JDK-8317349)).
>> 
>> Below is a sample screenshot (IGV print level 4 ) mainly showing the new phase .
>> ![image](https://github.com/user-attachments/assets/16013cd4-6ec6-4939-ac66-33bb03d59cd6)
>> 
>> Questions to reviewers: 
>> - Is the new macro elimination phase OK, or should we change anything?
>> - In `compile.cpp `, `PHASE_ITER_GVN_AFTER_ELIMINATION` follows `PHASE_AFTER_MACRO_ELIMINATION` in the current fix. Should `PHASE_ITER_GVN_AFTER_ELIMINATION` be removed ? 
>> 
>> Testing:
>> GitHub Actions
>> tier1 to tier5 on windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64.
>> Tested that thousands of graphs are correctly opened and visualized with IGV using the same test used in  ([JDK-8317349](https://bugs.openjdk.org/browse/JDK-8317349))
>
> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review on code style and adding failing

Nice cleanup! Please see my code comments.

> Is the new macro elimination phase OK, or should we change anything?

I think it looks reasonable, but please see my code comments.

> In compile.cpp , PHASE_ITER_GVN_AFTER_ELIMINATION follows PHASE_AFTER_MACRO_ELIMINATION in the current fix. Should PHASE_ITER_GVN_AFTER_ELIMINATION be removed ?

Let's leave it, as there is an IGVN run in between them.

src/hotspot/share/opto/compile.cpp line 2535:

> 2533:     print_method(PHASE_BEFORE_MACRO_EXPANSION, 3);
> 2534:     PhaseMacroExpand  mex(igvn);
> 2535:     //Last attempt to eliminate macro nodes before expand

Suggestion:

    // Last attempt to eliminate macro nodes before expand

src/hotspot/share/opto/macro.cpp line 2468:

> 2466:       }
> 2467:     }
> 2468: 

Suggestion:

src/hotspot/share/opto/macro.cpp line 2482:

> 2480:     return;
> 2481:   }
> 2482:   refine_strip_mined_loop_macro_nodes();

This call is later compared to before, right? In the previous version of `expand_macro_nodes`, it ran before the call to `eliminate_macro_nodes`. Is it safe to move it in this way?

src/hotspot/share/opto/macro.cpp line 2554:

> 2552: bool PhaseMacroExpand::expand_macro_nodes() {
> 2553:   // Do not allow new macro nodes once we started to expand
> 2554:   C->reset_allow_macro_nodes();

Same here, this call is later compared to before (it is at the top of the old `expand_macro_nodes`, before `eliminate_macro_nodes`). Is this a safe move?

src/hotspot/share/opto/macro.hpp line 1:

> 1: /*

Needs a copyright update!

src/utils/IdealGraphVisualizer/README.md line 36:

> 34: * `N=3`: additionally, after every minor phase
> 35: * `N=4`: additionally, after every loop optimization
> 36: * `N=5`: additionally, after every effective IGVN, and every macro elimination and expansion step (slow)

Suggestion:

* `N=5`: additionally, after every effective IGVN, macro elimination, and macro expansion step (slow)

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

Changes requested by dlunden (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25682#pullrequestreview-2925252596
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145350347
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145353088
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145361681
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145364636
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145368330
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2145370791