On Wed, 9 Sep 2026 05:15:00 GMT, Jatin Bhateja <[email protected]> wrote:
>> Patch optimizes Vector.slice operation with constant index using x86 ALIGNR >> instruction. >> Intrinsification is performed using new hybrid call generator infrastructure >> added along with https://github.com/openjdk/jdk/pull/30876 which performs >> lazy intrinsification and in case of intrinsic failure which will happen for >> variable slice index will perform procedural inlining of fallback >> implementation to prevent call overhead and boxing penalties. The existing >> vector API-based slice implementation is now the fallback code. >> >> Vector API jtreg tests pass at various AVX levels. >> >> Following are the performance numbers of benchmark included with the patch:- >> >> >> <img width="985" height="953" alt="image" >> src="https://github.com/user-attachments/assets/dfd7d540-bd9c-4349-a0d6-f78cb5304bfb"; >> /> >> <img width="986" height="487" alt="image" >> src="https://github.com/user-attachments/assets/78f01e67-74fa-41ce-8bc3-1d6ea2e54243"; >> /> >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Jatin Bhateja has updated the pull request incrementally with one additional > commit since the last revision: > > Regenerating jdk.incubator.vector sources post merge Very nice work. I have a few improvement suggestions. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7134: > 7132: // res[255:128] = {src2[127:0] , src1[255:128]} >> SHIFT > 7133: vperm2f128(dst, src1, src2, 0x21); > 7134: vpalignr(dst, dst, src1, origin, Assembler::AVX_256bit); For origin==8, it is better to use: vshufps(dst, src1, dst, 0x4E, Assembler::AVX_256bit); instead of vpalignr. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7148: > 7146: // res[255:128] = {src2[255:128] , src2[127:0]} >> (SHIFT - 16) > 7147: vperm2f128(dst, src1, src2, 0x21); > 7148: vpalignr(dst, src2, dst, origin - 16, Assembler::AVX_256bit); For origin==24, it is better to use: vshufps(dst, dst, src2, 0x4E, Assembler::AVX_256bit); instead of vpalignr. src/hotspot/share/opto/vectorIntrinsics.cpp line 1841: > 1839: Node* origin_node = gvn().intcon(origin->get_con() * > type2aelembytes(elem_bt)); > 1840: const TypeVect* vector_type = TypeVect::make(elem_bt, num_elem); > 1841: Node* operation = gvn().transform(trace_vector(new > VectorSliceNode(v1, v2, origin_node, vector_type))); For subword vectors of length > 16 with mid range byte origin (16 < byte origin < 48) there seems to be a regression. This is due to having three shuffle ops (valignd+valignd+valignr), we could instead rewrite this case with VectorLoadConst followed by SelectFromTwoVector where supported. The compiler would then hoist the VectorLoadConst above the loop and it would be just vpermi2b/w inside the loop. Node* iota = gvn().transform(new VectorLoadConstNode(gvn().makecon(TypeInt::ZERO), vector_type)); Node* bcast = gvn().transform(VectorNode::scalar2vector(gvn().intcon(origin->get_con()), num_elem, elem_bt)); Node* index = gvn().transform(VectorNode::make(add_vopc, iota, bcast, vector_type)); operation = gvn().transform(trace_vector(new SelectFromTwoVectorNode(index, v1, v2, vector_type))); ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-5183921859 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r3993889524 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r3993892076 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r3994358007
