RFR: 8366427: C2 SuperWord: refactor VTransform scalar nodes

[Vladimir Kozlov]

On Fri, 29 Aug 2025 15:45:24 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I feared this might get a question ;)
>> 
>> I'd like to do it this way, and later there will need to be more changes. There will also be changes for `_nodes` in the vector nodes.
>> 
>> Below some more thoughts - reading optional ;)
>> 
>> --------------------------------------
>> 
>> `VTransformNode` is too high up - it is the superclass of all. And not all have a `node`. The vector nodes have a list of nodes.
>> 
>> One option would be re-introducing some `VTransformScalarNode` that does nothing but hold that shared `_node` field. But I'd like to avoid having a public accessor for all of the subclasses. But picking a good name that unites all the subclasses is not so easy (data, memory, CFG, ... ). Conceptually, having such an in-between-class is not very helpful I fear.
>> 
>> In the long-run, we will probably not just have the "identity transform" with `_node`, but these 3:
>> - identity transform: reference a `node`, and keep it (maybe rewire inputs if memory is reordered).
>> - add new node, where there is no old reference (e.g. `VTransformConvI2LNode`, there will be more like extract).
>> - copy node: if we ever do "virtual unrolling" / widening, some nodes may not be vectorized (widened) and instead need to be duplicated/copied.
>> 
>> So maybe eventually I'll need more than just a `_node`:
>> - `_node`: for identity transform or copy
>> - an opcode to generate a new node
>> - an enum that says if we do: identity vs copy vs generate
>> 
>> We might need to a similar thing for vector nodes `_nodes`.
>> 
>> It is a little hard to model everything perfectly at the current state, without introducing massive code changes.
>> I'd rather "atomize" everything and duplicate some code now. Later, it will be easier to unite things again.
>> 
>> It is possible that I'll end up with something that covers everything, and put it in `VTransformNode`:
>> - something like `VTransformNodePrototype` in the POC PR https://github.com/openjdk/jdk/pull/20964.
>>   - `_node`: a reference for identity transform, copy. But even if we create a new node, we might want to have an "approximate origin" to copy the node notes from.
>>   - enum that says if we do identity vs copy vs generate
>>   - `vlen`: 1 for scalar, >1 for vector
>>   - `element_type` (BasicType)
>>   - `opcode`: the target opcode (scalar opcode when scalar, vector if to be vectorized)
>
> FYI: I have a bit of an overview of the tasks here:
> https://bugs.openjdk.org/browse/JDK-8340093

You put a lot of thoughts into this ;^) Okay, it is not big issue. It is just "natural" reaction from C++ programmer when he see a field duplication in subclasses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27002#discussion_r2310643738