RFR: 8366427: C2 SuperWord: refactor VTransform scalar nodes [v3]

[Emanuel Peter]

> 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.
> 
> The goal is to split up some cases that are currently treated the same, but will alter have different behavior. There may be a little bit of code duplication, but the code will soon be made different ;)
> 
> We split the `VTransformScalarNode`:
> - `VTransformMemopScalarNode`
>   - Uses that only wanted scalar mem nodes can now directly check for `isa_MemopScalar`.
>   - We can directly store the `_vpointer` in a field, that way we don't need to do a lookup via `vloop_analyzer`. This could also be helpful later on if we ever do widening (unrolling during auto vectorization): we could then do the necessary modifications to the `vpointer`.
> - `VTransformLoopPhiNode`
>   - Later on, they will play a more special role, they will give us easy access to the beginning state of the loop body and the backedges.
> - `VTransformCFGNode`
>   - Calling them scalar nodes is not 100% accurate. We'll probably have to further refine them later on. But splitting them off now seems like a reasonable choice. Once we do if-conversion we'll have to do more work on CFG.
> - `VTransformDataScalarNode`
>   - These represent all the normal "calculation" nodes in the loop.
> - `VTransformInputScalarNode` -> `VTransformOuterNode`:
>   - For now, we are still just tracking input nodes, but soon we will need to track input and output nodes: basically just the 1-hop neighbourhood of nodes outside the loop. I'm already renaming them now, so it will be less noise later.
> 
> I decided to rather split up more, and avoid the `VTransformScalarNode` together, avoiding having to override overrides - that can be really confusing (e.g. what I had with `is_load_in_loop`).

Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'JDK-8366427-VTransform-scalar-node-refactor' of https://github.com/eme64/jdk into JDK-8366427-VTransform-scalar-node-refactor
 - Update src/hotspot/share/opto/vtransform.hpp
   
   Co-authored-by: Manuel Hässig <manuel at haessig.org>
 - manual merge
 - improve print_spec
 - rm comment
 - InputScalar -> Outer renaming
 - rm useless methods
 - rm vloop_analyzer from vpointer method
 - JDK-8366427
 - JDK-8366361
 - ... and 3 more: https://git.openjdk.org/jdk/compare/56713817...86e88f43

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

Changes: https://git.openjdk.org/jdk/pull/27002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27002&range=02
  Stats: 157 lines in 4 files changed: 114 ins; 0 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/27002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27002/head:pull/27002

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