RFR: 8317349: Randomize order of macro node expansion in C2

Christian Hagedorn chagedorn at openjdk.org
Mon Feb 5 14:33:06 UTC 2024


On Fri, 2 Feb 2024 13:03:53 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

> This changeset adds a flag `StressMacroExpansion` which randomizes macro expansion ordering for stress testing purposes.
> 
> Changes:
> - Implement the flag `StressMacroExpansion`.
> - Add functionality tests for `StressMacroExpansion`, analogous to testing for previous stress flags such as `StressIGVN`.
> - Add `StressMacroExpansion` to a number of tests that already turn on all other stress flags (and therefore should also use `StressMacroExpansion`).
> - Rename the previous compiler phase `MACRO_EXPANSION` to `AFTER_MACRO_EXPANSION`.
> - Add new Ideal phases related to macro expansion, allowing `StressMacroExpansion` testing. Below is a sample phase list screenshot including some of the new phases (IGV print level 4).
>    <p align="center">
>       <img src="https://github.com/openjdk/jdk/assets/4222397/b65c67a0-13f7-45a6-aef4-5dfe259dab66" width="300">
>    </p>
> 
> 
> Question for the review: are the new macro expansion Ideal phases OK, or should we change anything?
> 
> Testing:
> - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/7756242938)
> - 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.

That's a nice stress option! I have a few comments.

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

> 5124: }
> 5125: 
> 5126: // Shuffle macro nodes

I think you can remove this comment as it should be clear from the method name.

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

> 5126: // Shuffle macro nodes
> 5127: void Compile::shuffle_macro_nodes() {
> 5128:   if (_macro_nodes.length() < 2) return;

I suggest to add braces:
Suggestion:

  if (_macro_nodes.length() < 2) {
    return;
  }

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

> 2436:   if (StressMacroExpansion) {
> 2437:     C->shuffle_macro_nodes();
> 2438:   }

I suggest to do this already before `eliminate_macro_nodes()` to also get a different macro node elimination order if multiple nodes could be removed.

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

> 2515:       assert(!success || (C->macro_count() == (old_macro_count - 1)), "elimination must have deleted one node from macro list");
> 2516:       progress = progress || success;
> 2517:       if (success) { C->print_method(PHASE_AFTER_MACRO_EXPANSION_ELIMINATE, 4, n); }

I suggest to put it on a new line. 
Suggestion:

      if (success) { 
        C->print_method(PHASE_AFTER_MACRO_EXPANSION_ELIMINATE, 4, n); 
      }

I think dumping at level 4 (same for the other newly added dumps) is too verbose already but when dumping at level 5, you have the overhead of additional IGVN step dumps. I could imagine that you either want macro expansion dumps OR IGVN step dumps but not always both. So, it looks like we've now reached a point where it would have been nice to enable/disable certain dumps. 

Anyway, since this is not possible I suggest to move these dumps to level 5 for now. But I'm open for other opinions about that.

test/hotspot/jtreg/compiler/c2/TestModDivTopInput.java line 31:

> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressMacroExpansion
> 30:  *                   -Xcomp -XX:CompileOnly=TestModDivTopInput::* -XX:-TieredCompilation -XX:StressSeed=87628618 TestModDivTopInput
> 31:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressMacroExpansion

I think we should not add this option here as this test was written as a regression test that should trigger a specific bug with the originally provided flags.

test/hotspot/jtreg/compiler/loopopts/TestPeelingSkeletonPredicateInitialization.java line 35:

> 33:  *             we do not statically realize that the peeled loop can never be entered.
> 34:  *
> 35:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN -XX:+StressMacroExpansion

Same here, I would not add this option here since it's a regression test for a specific bug.

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

PR Review: https://git.openjdk.org/jdk/pull/17684#pullrequestreview-1862869511
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478295898
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478295522
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478309545
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478305556
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478313313
PR Review Comment: https://git.openjdk.org/jdk/pull/17684#discussion_r1478335110


More information about the hotspot-compiler-dev mailing list