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