JDK-8366702 : C2 SuperWord: refactor VTransform vector nodes
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-09-02
  • Updated: 2025-09-15
  • Resolved: 2025-09-11
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 b15Fixed
Related Reports
Blocks :  
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
See plan overfiew: JDK-8340093

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

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

I have to say: I'm very sorry for this refactoring. I took some decisions in JDK-8332163 that I'm now partially undoing. I moved too much logic from SuperWord::output (now called SuperWordVTransformBuilder::make_vector_vtnode_for_pack) to the VTransform...Node::apply.

I had accidentially made the VTransformGraph too close to the PackSet, and not close enough to the future vectorized C2 Graph. And that makes some future changes hard.

My vision:

- VLoop / VLoopAnalyzer look at the scalar loop and prepare it for SuperWord
- SuperWord creates the PackSet: some nodes are packed, all others are scalar.
- SuperWordVTransformBuilder converts the PackSet into the VTransformGraph
- The VTransformGraph very closely represents the C2 vectorized loop after vectorization
  - It does not need to know which nodes it packs, it rather just needs to know how to generate the new vector nodes
  - That means it is straight-forward to compute cost
  - And it also makes optimizations on that graph easier
  - And the apply methods are simpler too

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

So therefore, the main goal was to make the VTransform...Node::apply calls simpler again. And move the logic back to SuperWordVTransformBuilder::make_vector_vtnode_for_pack.

One important step to making the the VTransformGraph less of a PackSet is to remove reliance on nodes for the vector nodes.

What I did:
- Moving a lot of the logic in VTransformElementWiseVectorNode::apply to SuperWordVTransformBuilder::make_vector_vtnode_for_pack.
  - Will make it easier to optimize and compute cost in future RFE's.
- VTransformVectorNodePrototype: packs a lot of the info for VTransformVectorNode.
  - pass info about bt, vlen, sopc instead of the pack -> allows us to eventually remove the dependency on nodes.
- New vector nodes, they are special cases I split away from VTransformElementWiseVectorNode:
  - VTransformReinterpretVectorNode
  - VTransformElementWiseLongOpWithCastToIntVectorNode
  - VTransformCmpVectorNode
 - Rename set_all_req_with_vectors -> init_all_req_with_vectors (forgot it in JDK-8366361)
 - A few smaller changes / refactorings.
Comments
Changeset: 4cc75be8 Branch: master Author: Emanuel Peter <epeter@openjdk.org> Date: 2025-09-11 05:03:21 +0000 URL: https://git.openjdk.org/jdk/commit/4cc75be80e6a89e0ed293e2f8bbb6d0f94189468
11-09-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27056 Date: 2025-09-02 15:30:06 +0000
05-09-2025