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