On Thu, 19 Feb 2026 06:54:40 GMT, Quan Anh Mai <[email protected]> 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
