RFR: 8373502: C2 SuperWord: speculative check uses VPointer variable was pinned after speculative check, leading to bad graph

[Emanuel Peter]

Thanks for @chhagedorn and @rwestrel for triaging / doing some first investigation.

This is a regression of [JDK-8324751](https://bugs.openjdk.org/browse/JDK-8324751) / https://github.com/openjdk/jdk/pull/24278.

This is almost the same as https://github.com/openjdk/jdk/pull/28449, so have a quick look at it.
It was also an issue with some nodes being pinned too low, and not available at the speculative check.
There, it was the `pre_init` values of the `iv`. Now it is the variables of the `VPointer`.
The fix is pretty similar as well.

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

**Analysis**

The reproducer gets a `bad graph` assert because of this cycle:
<img width="885" height="788" alt="image" src="https://github.com/user-attachments/assets/f2992470-5452-4fb2-841e-353f753d9cbd" />
Note: `921 CountedLoop` is the pre-loop, the main-loop is further down from it.
And `607 ParsePredicate` is the `#Auto_Vectorization_Check`, and `1403` is the aliasing check inserted for the VPointer named below.

This is the relevant VPointer:
`VPointer[size: 4, object, base(920 CastPP) + con( 20) + iv_scale( 0) * iv + invar(0)]`
The base `920 CastPP` is the problematic variable.

In `VPointer::init_are_non_iv_summands_pre_loop_invariant`, we check that:
`_vloop.is_pre_loop_invariant(variable)`
And that holds for `920 CastPP`. So far so good.

This used to be enough when we only adjusted the pre-loop limit for alignment.
But now that we need the variables for the aliasing runtime check further up, this is not sufficient any more. Analogue to https://github.com/openjdk/jdk/pull/28449, we would now need:
`this->_vloop.is_available_for_speculative_check(variable)`
And that is false for `920 CastPP`, since it is pinned after the speculative check.

**Solution**
We should not insert the aliasing runtime check, and hence we probably cannot vectorize this case.

For now, this makes all tests pass. I think just like with https://github.com/openjdk/jdk/pull/28449 these cases are edge cases we don't have to worry too much about. But if they ever do become important, we could try to uncast the variables. But I don't know if that is without issues, we would certainly lose some info that we get from the casts.

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

Commit messages:
 - fix up detail
 - JDK-8373502

Changes: https://git.openjdk.org/jdk/pull/28783/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373502
  Stats: 113 lines in 3 files changed: 113 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28783/head:pull/28783

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