RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v13]

[Jatin Bhateja]

On Thu, 19 Feb 2026 06:54:40 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > Even after we have constant shuffle and constant mask recognizing the slice idiom and recovering origin remains highly non-trivial
> 
> I think you are misunderstanding, when `TypeVect` has constant information, the shuffle indices and the blend mask will constant fold, and there is no `iotaShuffle` subgraph or the compare-with-constant node there to inspect to extract the `origin`.

Given that vector lane itself are variable an application of constant shuffle will not fold rearrange, so a complex pattern match to infer VectorSliceNode (with constant index) probably in blend idealization will still have to deal with a graph pallet consisting of blend with constant mask, two re-arrange nodes with constant shuffles, and some other non-folded nodes.


    /*package-private*/
    final
    @ForceInline
    IntVector sliceTemplate(int origin, Vector<Integer> v1) {
        IntVector that = (IntVector) v1;
        that.check(this);
        Objects.checkIndex(origin, length() + 1);
        IntVector iotaVector = (IntVector) iotaShuffle().toBitsVector();
        IntVector filter = broadcast((int)(length() - origin));
        VectorMask<Integer> blendMask = iotaVector.compare(VectorOperators.LT, filter);
        AbstractShuffle<Integer> iota = iotaShuffle(origin, 1, true);
        return that.rearrange(iota).blend(this.rearrange(iota), blendMask);
    }


I think its reasonable to proceed with the hybrid call generator for **this PR** so we can ship a reliable slice optimization (including for use cases like simdjson) without taking on the full cost and risk of TypeVect constant info and slice-pattern matching right now. In future once constant TypeVect are in production we can replace existing intrinsification approach with patten match and still use the backend implementation as it is.

Let think over it and also seek other's opinion (@sviswa7)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3925170985