On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhat...@openjdk.org> wrote:
>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR
>> instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification
>> or else perform procedural inlining to prevent call overhead and boxing
>> penalties in case the fallback implementation expects to operate over
>> vectors. The existing vector API-based slice implementation is now the
>> fallback code that gets inlined in case intrinsification fails.
>>
>> Idea here is to add infrastructure support to enable intrinsification of
>> fast path for selected vector APIs, else enable inlining of fall-back
>> implementation if it's based on vector APIs. Existing call generators like
>> PredictedCallGenerator, used to handle bi-morphic inlining, already make use
>> of multiple call generators to handle hit/miss scenarios for a particular
>> receiver type. The newly added hybrid call generator is lazy and called
>> during incremental inlining optimization. It also relieves the inline
>> expander to handle slow paths, which can easily be implemented library side
>> (Java).
>>
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>>
>> Performance numbers:
>>
>>
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>>
>> Baseline:
>> Benchmark (size) Mode Cnt
>> Score Error Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2
>> 9444.444 ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2
>> 10009.319 ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2
>> 9081.926 ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2
>> 6085.825 ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2
>> 6505.378 ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2
>> 6204.489 ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2
>> 1651.334 ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2
>> 1642.784 ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2
>> 1474.808 ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2
>> 10399.394 ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2
>> 10502.894 ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updating predicate checks
src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7138:
> 7136: // res[255:128] = {src2[127:0] , src1[255:128]} >> SHIFT
> 7137: vperm2i128(xtmp, src1, src2, 0x21);
> 7138: vpalignr(dst, xtmp, src1, origin, Assembler::AVX_256bit);
If the slice amount is exactly 16, I think the `vpalignr` is unnecessary.
src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 7159:
> 7157: void C2_MacroAssembler::vector_slice_64B_op(XMMRegister dst,
> XMMRegister src1, XMMRegister src2,
> 7158: XMMRegister xtmp, int
> origin, int vlen_enc) {
> 7159: if (origin <= 16) {
If `origin` is divisible by `4`, then a single `valignd` is enough, am I right?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260699543
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2260702518
