8375442: C2: Notify nodes that inspect the graph deeply of changes far away during IGVN

[krk]

Some C2 IGVN node types inspect the graph far beyond their direct inputs (walking dominator chains, memory chains, or control flow) and miss optimization opportunities when changes happen far away. The affected types are If/RangeCheck, Load, CmpP with oop pointers, and CountedLoopEnd/LongCountedLoopEnd.

This patch adds a deep revisit pass that, after the main IGVN worklist drains, re-enqueues all live deep-inspection nodes for re-evaluation, repeating until convergence or a maximum of 10 rounds.

Existing Load/CmpP value-verification exceptions are tightened to only apply when deep revisit was not performed. The Ideal-verification exceptions for If, RangeCheck, Load, CountedLoopEnd, and LongCountedLoopEnd are not tightened because Ideal(can_reshape=true) is destructive and contaminates subsequent verification. These are instead verified via a drain-based convergence check in verify_optimize().

A new develop flag UseDeepIGVNRevisit (default true) gates the feature.

The new test covers RangeCheck elimination only; the other node types tend to trigger in larger methods.

Benchmark

On the Renaissance 0.16.1 dotty benchmark (Scala compiler, 10 repetitions), deep revisit showed a ~12% wall_time improvement and ~3% reduction in CPU cycles, measured with Performance Optimizer Observation Platform. Deep revisit triggered in 496 compilations, removing 12493 nodes total.

Please note that this was measured on a noisy laptop with 3 runs. UseDeepIGVNRevisit was temporarily promoted to a product flag for this benchmark so it could be toggled on a release build:

poop -d 30000 -s \
  "build/linux-x86_64-server-release/jdk/bin/java -XX:-UseDeepIGVNRevisit -jar $REN_16_1_JAR dotty -r 10 --no-forced-gc" \
  "build/linux-x86_64-server-release/jdk/bin/java -XX:+UseDeepIGVNRevisit -jar $REN_16_1_JAR dotty -r 10 --no-forced-gc"

Benchmark 1 (3 runs): ... -XX:-UseDeepIGVNRevisit ...
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          36.7s  ± 2.15s     35.3s  … 39.1s           0 ( 0%)        0%
  peak_rss           1.14GB ± 7.14MB    1.14GB … 1.15GB          0 ( 0%)        0%
  cpu_cycles         96.3G  ± 6.34G     91.2G  …  103G           0 ( 0%)        0%
  instructions        150G  ± 10.5G      143G  …  162G           0 ( 0%)        0%
  cache_references   1.67G  ± 80.8M     1.62G  … 1.76G           0 ( 0%)        0%
  cache_misses        480M  ± 6.89M      472M  …  484M           0 ( 0%)        0%
  branch_misses       794M  ± 44.8M      764M  …  845M           0 ( 0%)        0%
  --- SIMD/FP instructions (Intel) ---
  scalar_double      40.5M  ± 3.43M     38.1M  … 44.4M           0 ( 0%)        0%
  scalar_single      1.41M  ± 71.3K     1.35M  … 1.49M           0 ( 0%)        0%
  128b_packed_double  532   ± 97.8       445   …  638            0 ( 0%)        0%
  128b_packed_single  343   ± 19.7       331   …  366            0 ( 0%)        0%
  256b_packed_double    0   ±    0         0   …    0            0 ( 0%)        0%
  256b_packed_single    0   ±    0         0   …    0            0 ( 0%)        0%
Benchmark 2 (3 runs): ... -XX:+UseDeepIGVNRevisit ...
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          32.2s  ± 1.22s     31.4s  … 33.6s           0 ( 0%)        ⚡- 12.2% ± 10.8%
  peak_rss           1.14GB ± 12.2MB    1.13GB … 1.16GB          0 ( 0%)          -  0.3% ±  2.0%
  cpu_cycles         93.2G  ± 1.05G     92.1G  … 94.2G           0 ( 0%)          -  3.2% ± 10.7%
  instructions        155G  ± 2.62G      153G  …  158G           0 ( 0%)          +  3.8% ± 11.6%
  cache_references   1.71G  ± 32.9M     1.69G  … 1.75G           0 ( 0%)          +  2.4% ±  8.4%
  cache_misses        463M  ± 20.6M      441M  …  481M           0 ( 0%)          -  3.4% ±  7.2%
  branch_misses       818M  ± 14.2M      803M  …  832M           0 ( 0%)          +  3.0% ±  9.5%
  --- SIMD/FP instructions (Intel) ---
  scalar_double      40.7M  ± 1.21M     40.0M  … 42.1M           0 ( 0%)          +  0.6% ± 14.4%
  scalar_single      1.39M  ± 34.4K     1.35M  … 1.41M           0 ( 0%)          -  1.4% ±  9.0%
  128b_packed_double  733   ±  141       611   …  887            0 ( 0%)          + 37.8% ± 51.6%
  128b_packed_single  386   ± 34.6       346   …  410            0 ( 0%)          + 12.3% ± 18.6%
  256b_packed_double    0   ±    0         0   …    0            0 ( 0%)          -  nan% ± -nan%
  256b_packed_single    0   ±    0         0   …    0            0 ( 0%)          -  nan% ± -nan%

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8375442: C2: Notify nodes that inspect the graph deeply of changes far away during IGVN (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/29721/head:pull/29721
$ git checkout pull/29721

Update a local copy of the PR:
$ git checkout pull/29721
$ git pull https://git.openjdk.org/jdk.git pull/29721/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 29721

View PR using the GUI difftool:
$ git pr show -t 29721

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/29721.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back krk! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@krk The following label will be automatically applied to this pull request:

• hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (fd2847f9)

[merykitty]

The Ideal-verification exceptions for If, RangeCheck, Load, CountedLoopEnd, and LongCountedLoopEnd are not tightened because Ideal(can_reshape=true) is destructive and contaminates subsequent verification. These are instead verified via a drain-based convergence check in verify_optimize().

I don't understand this part. If the verification succeeds, it means there should be no transformation performed by Ideal, otherwise, if it does perform some transformations and thus has a chance to contaminate subsequent verification, the verification has already failed. Am I missing something here?