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

Saranya Natarajan snatarajan at openjdk.org
Tue Jun 17 14:13:39 UTC 2025


On Fri, 13 Jun 2025 15:36:26 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> Saranya Natarajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review on code style and adding failing
>
> 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?

This placement of ` refine_strip_mined_loop_macro_nodes()` is ok as it only affects the functionality in the loop of the `eliminate_opaque_looplimit_macro_nodes` method.

> 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?

I believe, this is also fine. However, I have moved it to `compile.cpp` to mimic the scenario as done previously before this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2152381926
PR Review Comment: https://git.openjdk.org/jdk/pull/25682#discussion_r2152383946


More information about the hotspot-compiler-dev mailing list