On Thu, 16 Apr 2026 04:45:58 GMT, Jatin Bhateja <[email protected]> wrote:
>> src/hotspot/share/opto/compile.hpp line 480: >> >>> 478: >>> 479: GrowableArray<CallGenerator*> _vector_reboxing_late_inlines; // same >>> but for vector reboxing operations >>> 480: GrowableArray<CallGenerator*> _vector_late_inlines; // inline >>> fallback implementation for failed intrinsics >> >> What's the motivation for a separate list? Why don't you perform fallback >> inlining when intrinsification attempt fails? > > It was to give intrinsic another chance to succeed if it fails due to > non-constant context on first attempt, > https://github.com/openjdk/jdk/pull/24104#discussion_r2814976511 > > Currently, if intrinsification fails then we set the generator for > CallStaticJavaNode in `Compile::inline_incrementally_one` > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L2108 > > `Compile::inline_incrementally_cleanup` called after > `Compile::inline_incrementally_one` internally calls IGVN optimizations > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L2213 > > CallStaticJavaNode idealization then re-injects the the failed intrinsic call > node to _late_inlines list for another intrinsification attempt. > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/callnode.cpp#L1175 > > If we inline the fallback on first intrinsification failure then we loose > another opportunity to intrinsify, _vector_late_inlines collects such > callgenerators and then once we are through with intrinsification attempts it > inline the failed intrinsic calls towards the end on the lines of > _string_late_inlines. > > https://github.com/openjdk/jdk/pull/24104/changes#diff-f076857d7da81f56709da3de1511b1105727032186cde4d02c678667761f46eaR2252 Ok, but you could delay vector operation intrinsification until a full round of late inlining is over and then dispatch between intrinsic and fallback implementation. Overall, I'm not fully satisfied with current implementation. Please, extract it in a separate PR and let's discuss it there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r3095786372
