On Thu, 22 Jan 2026 08:31:30 GMT, Jatin Bhateja <[email protected]> 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 refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 Overall, looks good to me; I’ve just left a few minor comments. src/hotspot/share/opto/vectorIntrinsics.cpp line 1712: > 1710: log_if_needed(" ** vector slice from non-constant index not > supported"); > 1711: return false; > 1712: } Is it better floating this check up to an earlier line? Maybe followed line-1704 or merged into line-1689. src/hotspot/share/opto/vectornode.cpp line 2440: > 2438: > 2439: Node* VectorSliceNode::Identity(PhaseGVN* phase) { > 2440: if (origin()->is_Con()) { `origin` must be a constant now? src/hotspot/share/opto/vectornode.cpp line 2443: > 2441: jint index = origin()->get_int(); > 2442: uint vlen = vect_type()->length_in_bytes(); > 2443: if (vlen == (uint)index) { Suggestion: if (vlen == (uint) index) { src/hotspot/share/opto/vectornode.hpp line 1697: > 1695: class VectorSliceNode : public VectorNode { > 1696: public: > 1697: VectorSliceNode(Node* vec1, Node* vec2, Node* origin, const TypeVect* > vt) Do we need an assertion for `origin` which is always a constant ? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java line 2173: > 2171: FloatVector slice(int origin, Vector<Float> v1); > 2172: > 2173: Revert this new added blank line? ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3691494636 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716077178 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716083174 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716080787 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716090510 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716094647
