JDK-8366427 : C2 SuperWord: refactor VTransform scalar nodes
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-08-29
  • Updated: 2025-09-01
  • Resolved: 2025-09-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 masterFixed
Description
I'm working on cost-modeling, and am integrating some smaller changes from this proof-of-concept PR:
https://github.com/openjdk/jdk/pull/20964

This is a pure refactoring - no change in behaviour. I'm presenting it like this because it will make reviews easier.

The goal is to split up some cases that are currently treated the same, but will alter have different behavior. There may be a little bit of code duplication, but the code will soon be made different ;)

We split the VTransformScalarNode:

- VTransformMemopScalarNode
  - Uses that only wanted scalar mem nodes can now directly check for isa_MemopScalar.
  - We can directly store the _vpointer in a field, that way we don't need to do a lookup via vloop_analyzer.
  - This could also be helpful later on if we ever do widening (unrolling during auto vectorization): we could then do the necessary modifications to the vpointer.
- VTransformLoopPhiNode
  - Later on, they will play a more special role, they will give us easy access to the beginning state of the loop body and the backedges.
- VTransformCFGNode
  - Calling them scalar nodes is not 100% accurate. We'll probably have to further refine them later on.
  - But splitting them off now seems like a reasonable choice.
  - Once we do if-conversion we'll have to do more work on CFG.
- VTransformDataScalarNode
  - These represent all the normal "calculation" nodes in the loop.
- VTransformInputScalarNode -> VTransformOuterNode:
  - For now, we are still just tracking input nodes, but soon we will need to track input and output nodes: basically just the 1-hop neighbourhood of nodes outside the loop.
  - I'm already renaming them now, so it will be less noise later.

I decided to rather split up more, and avoid the VTransformScalarNode together, avoiding having to override overrides - that can be really confusing (e.g. what I had with is_load_in_loop).
Comments
Changeset: 99223eea Branch: master Author: Emanuel Peter <epeter@openjdk.org> Date: 2025-09-01 13:48:25 +0000 URL: https://git.openjdk.org/jdk/commit/99223eea03e2ed714f7a5408c356fdf06efc9200
01-09-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27002 Date: 2025-08-29 09:49:46 +0000
01-09-2025