RFR: 8369448: C2 SuperWord: refactor VTransform to do move_unordered_reduction_out_of_loop during VTransform::optimize

[Emanuel Peter]

On Wed, 8 Oct 2025 19:42:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> 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.
> 
> This should be the last one before Cost Modeling, which will enable us to vectorize more reductions 😊 
> 
> --------------------------
> 
> **Goal:** we need to do the `move_reduction_out_of_loop` already during auto vectorization, and not after. This will allow us to cost-model the loop after the expensive reduction nodes are removed from the loop in a following RFE.
> 
> **Details**
> Reduction nodes are expensive, and require many instructions in the backend. In some cases, this means that the vectorized reduction is more expensive than the scalar reduction. We would have to find other operations to vectorize, so that the instruction count goes down sufficiently. There are cases where the reduction is not profitable before `move_reduction_out_of_loop`, but profitable after.
> 
> Since we now modify `VTransformNode`s during `VTransform::optimize` (think of it as the IGVN for `VTransform`), some nodes can become dead, and so we need to take care of that with `is_alive`. And we must only schedule alive nodes, others may not have a coherent state.
> 
> **Future Work**
> - Cost Modeling [JDK-8340093](https://bugs.openjdk.org/browse/JDK-8340093)
> - Other optimizations that lower the cost of the vectorized loop, and enable vectorization to be profitable.

@vnkozlov Thanks for having a look. I updated the code :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27704#issuecomment-3387579767