RFR: 8312332: C2: Refactor SWPointer out from SuperWord
Emanuel Peter
epeter at openjdk.org
Thu Aug 10 12:37:29 UTC 2023
On Tue, 25 Jul 2023 08:51:38 GMT, Pengfei Li <pli at openjdk.org> wrote:
> As discussed in JDK-8308994, we should first do some refactoring work before proceeding with the new post loop vectorization. In this patch, we have done the following.
>
> 1) We have created new C2 source files `vectorization.[cpp|hpp]` for shared logics and utilities for C2's auto-vectorization. So far we have moved class `SWPointer` and `VectorElementSizeStats` here from `superword.[cpp|hpp]`.
>
> 2) We have decoupled `SWPointer` from class `SuperWord` and renamed it to `VPointer` as it will be used by vectorizers other than SuperWord. The original class `SWPointer` and its inner class `Tracer` both have a `_slp` field initialized in their constructors. In this patch, we have replaced them by other fields and re-written the constructors for the same functionality. Original `SWPointer::invariant()` calls function `SuperWord::find_pre_loop_end()` for loop invariant checks. To help decoupling, we moved function `find_pre_loop_end()` to class `CountedLoopNode`. As function `SWPointer::Tracer::invariant_1()` is tightly coupled with `SuperWord` but only prints some debug messages, we temporarily removed it in this patch. We will consider adding it back after later refactoring of `SuperWord` so we added a `TODO` at its call site in this patch.
>
> 3) We have a lot of memory phi node checks in loop optimizations. So we added a utility function `is_memory_phi()` in `node.hpp`.
>
> Tested tier1~3 on x86 and AArch64. Also manually verified that option `VectorizeDebug` in compiler directives still works well.
@pfustc Thanks a lot for moving this code, and especially for untangling it from SuperWord. This will be helpful for many future vectorization projects.
I left a few comments, but otherwise this looks straight-forward and good to me.
src/hotspot/share/opto/vectorization.cpp line 40:
> 38: #endif
> 39:
> 40: VPointer::VPointer(MemNode* mem, PhaseIdealLoop* phase, IdealLoopTree* lpt,
You could also call it `LPointer` or `LoopPointer`. `VPointer` sounds like `VectorPointer` - but it is not a pointer of a vector but a scalar memop. That could be confusing. But you could also argue it is a `VectorizationPointer`, and hence `VPointer.`
src/hotspot/share/opto/vectorization.cpp line 50:
> 48: _nstack(nstack), _analyze_only(analyze_only), _stack_idx(0)
> 49: #ifndef PRODUCT
> 50: , _tracer((phase->C->directive()->VectorizeDebugOption & 2) > 0)
You should also refactor the accessors for `VectorizeDebugOption`. I would move it from SuperWord to `vectorization.hpp/cpp` somehow. We should only do the "masking" `& 2` in one single place.
src/hotspot/share/opto/vectorization.cpp line 131:
> 129: bool VPointer::invariant(Node* n) const {
> 130: NOT_PRODUCT(Tracer::Depth dd;)
> 131: // TODO: Add more trace output for invariant check after later refactoring
We generally don't like `TODO`s in the code. Best is to just drop it in the code and file an RFE if you think it is really important.
When did this even trace anything?
`_slp->_lpt->is_member(_slp->_phase->get_loop(n_c)) != (int)_slp->in_bb(n)`
Do you think this tracing is relevant enough?
src/hotspot/share/opto/vectorization.cpp line 145:
> 143: Node* n_c = phase()->get_ctrl(n);
> 144: return phase()->is_dominator(n_c, pre_loop_end->loopnode());
> 145: }
Is `pre_loop_end != nullptr` possible here? Before your patch we always found `_slp->pre_loop_head()`.
I'm just worried that if we do not find it, then we still return `is_not_member`, but `n` is still located in the space between pre and post loop.
What do you think about this?
And: would it make sense to cache the `pre_loop_head` in the `VPointer`?
-------------
PR Review: https://git.openjdk.org/jdk/pull/15013#pullrequestreview-1571704233
PR Review Comment: https://git.openjdk.org/jdk/pull/15013#discussion_r1290037785
PR Review Comment: https://git.openjdk.org/jdk/pull/15013#discussion_r1290023212
PR Review Comment: https://git.openjdk.org/jdk/pull/15013#discussion_r1290006470
PR Review Comment: https://git.openjdk.org/jdk/pull/15013#discussion_r1290015263
More information about the hotspot-compiler-dev
mailing list