RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2]
Xiaohong Gong
xgong at openjdk.org
Tue Aug 12 06:01:29 UTC 2025
On Tue, 12 Aug 2025 05:55:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:
>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1714:
>>
>>> 1712: }
>>> 1713:
>>> 1714: Node* origin_node = gvn().intcon(origin->get_con() * type2aelembytes(elem_bt));
>>
>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
>>
>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such requirement. WDYT?
>
>> Q1: Is it possible that just passing `origin->get_con()` to `VectorSliceNode` in case there are architectures that need it directly? Or, maybe we'd better add comment telling that the origin passed to `VectorSliceNode` is adjust to bytes.
>>
>
> Added comments.
>
>> Q2: If `origin` is not a constant, and there is an architecture that support the index as a variable, will the code crash here? Can we just limit the `origin` to a constant for this intrinsifaction in this PR? We can consider to extend it to variable in case any architecture has such a requirement. WDYT?
>
> Currently, inline expander only supports constant origin. I have added a check to fail intrinsification and inline fallback using the hybrid call generator.
Thanks for your updating! So maybe the matcher function `supports_vector_slice_with_non_constant_index()` could also be removed totally?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2268675021
More information about the hotspot-dev
mailing list