RFR: 8343685: C2 SuperWord: refactor VPointer with MemPointer [v18]

Emanuel Peter epeter at openjdk.org
Sat Jan 18 06:07:59 UTC 2025


> **This is a required step towards adding runtime-checks for Aliasing Analysis, especially Important for FFM / MemorySegments.**
> See: https://eme64.github.io/blog/2025/01/01/AutoVectorization-Status.html
> 
> I know this one is large, but it consists of a lot of renamings, and new tests. On the whole, the new `VPointer` code is less than the old!
> 
> **Goal**
> 
> Replace old `VPointer` with a new version that relies on `MemPointer` - which then is a shared utility for both `MergeStores` and `SuperWord / AutoVectorization`. `MemPointer` generally parses pointers, and `VPointer` specializes this facility for the use in loops (`VLoop`).
> 
> The old `VPointer` implementation with its recursive pattern matching was quite complicated and difficult to reason about for correctness. The approach in `MemPointer` is much simpler: iteratively decomposing sub-expressions. Further: the new implementation is more powerful at detecting equivalent invariants.
> 
> **Future**:  with the `MemPointer` implementation of `VPointer`, it should be easier to implement speculative runtime-checks for Aliasing-Analysis [JDK-8324751](https://bugs.openjdk.org/browse/JDK-8324751). The pressing need for this has come from the FFM / MemorySegment folks, like @mcimadamore and @minborg .
> 
> **Details**
> 
> This looks like a rather big patch, so let me explain the parts.
> - Refactor of `MemPointer` in `mepointer.hpp/cpp`:
>   - Added concept of `Base` to `MemPointer`. This is required for the aliasing computation in `VPointer`.
>   - `sub_expression_has_native_base_candidate`: add special case to parse through `CastX2P` if we find a native memory base `MemorySegment.address()`, i.e. `jdk.internal.foreign.NativeMemorySegmentImpl.min`. This helps some native memory segment cases to vectorize that did not before.
>   - So far `MemPointer` could only answer adjacency queries. But VPointer also needs overlap queries, see the old `VPointer::not_equal` (i.e. can we prove that the two `VPointer` never overlap?). So I had to add a new case to aliasing computation: `NotOrAtDistance`. It is useful to answer the new and better named `MemPointer::never_overlaps_with`.
>   - Collapsed together `MemPointerDecomposedForm` and `MemPointer`. It was an unnecessary and unhelpful split.
> - Re-write of `VPointer` based on `MemPointer`:
>   - Old pattern:
>     - `VPointer[mem:  847     StoreI, base:   37, adr:   37,  base[  37] + offset(  16) + invar(   0) + scale(   4) * iv]`
>     - `VPointer[mem: 3189      LoadB, base:    1, adr: 2273,  base[   1] ...

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

 - Merge branch 'master' into JDK-8343685-VPointer-MemPointer
 - fix indent
 - for Christian
 - Apply suggestions from code review by Christiain
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Batch 2 for Christian
 - refactor to has_invar_summands and print invar and fix non-product guards
 - rename to has_same_invar_summands_and_iv_scale_as
 - split init_is_valid
 - remove dead code left behind after JDK-8311691
 - More comments for Christian
 - ... and 126 more: https://git.openjdk.org/jdk/compare/e1cf3517...79440e4b

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

Changes: https://git.openjdk.org/jdk/pull/21926/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21926&range=17
  Stats: 4207 lines in 18 files changed: 1965 ins; 1575 del; 667 mod
  Patch: https://git.openjdk.org/jdk/pull/21926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21926/head:pull/21926

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


More information about the hotspot-compiler-dev mailing list