RFR: 8295166: IGV: dump graph at more locations

[Daniel Lundén]

On Tue, 10 Oct 2023 13:31:00 GMT, Daniel Lundén <duke at openjdk.org> wrote:

> This changeset
> 1. adds a number of new graph dumps for IdealGraphVisualizer (IGV):
>    - Before conditional constant propagation
>    - After register allocation
>    - After block ordering
>    - After peephole optimization
>    - After post-allocation expansion
>    - Before and after
>      - loop predication
>      - loop peeling
>      - pre/main/post loops
>      - loop unrolling
>      - range check elimination
>      - loop unswitching
>      - partial peeling
>      - split if
>      - superword
> 2. adds support for enumeration of repeated IGV graph dumps.
> 3. adjusts IGV print levels to encompass the new graph dumps. The old levels 4 and 5 are now levels 5 and 6. The new level 4 is for loop optimization dumps.
> 
> Example phase list screenshots in IGV (first at level 6, second at level 4)
> ![Screenshot from 2023-12-04 13-55-38](https://github.com/openjdk/jdk/assets/4222397/6759dc5a-9c9a-42b9-8d9e-2d0b53e76ab4) ![Screenshot from 2023-12-04 13-56-29](https://github.com/openjdk/jdk/assets/4222397/44d6a239-587b-4f7c-8ce1-f7613cb2fa35)
> 
> 
> Some notes:
> - While discussing the above changes, a separate question was brought up by @chhagedorn:
>   > On a separate note, I'm wondering how useful it is to always dump all JFR events when calling print_method(). Should this be revisited again in general?
> - The new IGV graph dump enumeration enables a number of cleanups. There is now another RFE for IGV cleanup: [JDK-8319599](https://bugs.openjdk.org/browse/JDK-8319599).
> 
> ### Testing
> #### Platforms: windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64
> - tier1, tier2, tier3, tier4, tier5.
> - Check that optimized builds (`--with-debug-level optimized`) still work.
> 
> #### Platforms: linux-x64
> - Tested that thousands of graphs are correctly opened and visualized with IGV.

Thanks for the review Tobias!

> Please add an IGV screenshot of how the new phases look in the phase list.

I've attached two sample screenshots of the phase list (from running one of the tests in `hotspot/jtreg/compiler/loopopts/PartialPeelingUnswitch.java`). Note the enumeration of the loop optimizations and the attached target loop node indices.

![Screenshot from 2023-10-13 12-59-22](https://github.com/openjdk/jdk/assets/4222397/897a8a92-d275-4b06-9d63-720745ed099c)
![Screenshot from 2023-10-13 12-59-53](https://github.com/openjdk/jdk/assets/4222397/ed0840ea-4a49-4e70-affb-cb7b5eda92ad)


> Could you summarize which of the ideas / proposals from the RFE are not covered? We should file a follow-up RFE for them.

I believe I have covered everything in the RFE.

> Existing calls to print_method are not guarded because the method also commits a JFR event and updates Compile::_latest_stage_start_counter, so I think your new code should behave similar.

Ah, I see. Note, however, that the existing call to `print_method` for `PHASE_AFTER_ITER_GVN_STEP` (at level 4) is guarded. Also, the bytecode printing (level 5) is guarded (although it does not use `Compile::print_method`).

> And please make sure that you verify that the 'optimized' build (--with-debug-level optimized) still works. It's a level between fastdebug and release where both #ifdef ASSERT and #ifdef PRODUCT are false.

I'll make sure to include this when testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16120#issuecomment-1761349652