On Mon, 16 Feb 2026 14:06:29 GMT, Quan Anh Mai <[email protected]> wrote:
> I still think it is not a good solution to add an intrinsic method for this
> operation. We should add constant info to `TypeVect` and transform the slice
> pattern into `VectorSliceNode`. I think it is adequate to add bit info (zeros
> and ones) to each `TypeVect` instance so that we can do decent inference
> without too much additional memory overhead.
What you are asking for is a bigger change which can be taken up as a separate
RFE.
> src/hotspot/share/opto/callGenerator.cpp line 703:
>
>> 701: // Attempt inlining fallback implementation in case of
>> 702: // intrinsification failure.
>> 703: if (new_jvms == nullptr && is_vector_late_inline()) {
>
> This may be problematic if the intrinsification does not succeed because the
> arguments have not been constant-folded. It is because the order in which
> methods are processed during incremental inline is not deterministic.
Hi @merykitty , Intrinsicification failure due to any such reason is same with
and without this patch, in case of intrinsic failure we simply inline the
fallback implementation which is comprised of vector APIs, VectorSupport* entry
points of APIs should then go through intrinsification attempts independently.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3909009433
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2812897947
