On Mon, 16 Feb 2026 15:12:54 GMT, Jatin Bhateja <[email protected]> wrote:
> What you are asking for is a bigger generic change which can be taken up as a
> separate RFE once this is committed.
I think there is no need to rush this functionality, and this will become
unnecessary when `TypeVect` can track const-ness of the value, so we should not
proceed with this change.
>> 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 slice 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 and may succeeded or fail if constraints are not met.
`CallStaticJavaNode::Ideal` will enqueue the call for incremental inline again
when it is invoked. That means if the method fails to get intrinsified at
first, then its arguments constant-fold, then the intrinsification may succeed
upon retry.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3912278853
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2814976511
