RFR: 8366702: C2 SuperWord: refactor VTransform vector nodes

Emanuel Peter epeter at openjdk.org
Fri Sep 5 13:51:21 UTC 2025


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.](https://bugs.openjdk.org/browse/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 https://github.com/openjdk/jdk/pull/19719 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`. https://github.com/openjdk/jdk/pull/19719  was a roughly 1.5k line change, and I took about a 0.3k misstep that I'm now correcting here ;)

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 #26991)
- A few smaller changes / refactorings.

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

Commit messages:
 - fix merge
 - manual merge conflict resolution
 - flatten
 - cleanup
 - adr_type refactor
 - hide prototype
 - wip x1
 - wip continued 2
 - wip continued
 - wip cleanup
 - ... and 13 more: https://git.openjdk.org/jdk/compare/0dad3f1a...05ee2800

Changes: https://git.openjdk.org/jdk/pull/27056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366702
  Stats: 327 lines in 4 files changed: 169 ins; 55 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/27056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27056/head:pull/27056

PR: https://git.openjdk.org/jdk/pull/27056


More information about the hotspot-compiler-dev mailing list