RFR: 8266854: LibraryCallKit::inline_preconditions_checkIndex modifies control flow even if the intrinsic bailed out
Sandhya Viswanathan
sviswanathan at openjdk.java.net
Tue May 11 01:00:59 UTC 2021
On Mon, 10 May 2021 23:56:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>> LibraryCallKit::inline_preconditions_checkIndex can result in the following assert sometimes:
>> "# assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out"
>>
>> Consider the following code snippet:
>> ...
>> set_control(_gvn.transform(new IfTrueNode(rc)));
>> {
>> PreserveJVMState pjvms(this);
>> set_control(_gvn.transform(new IfFalseNode(rc)));
>> uncommon_trap(Deoptimization::Reason_range_check,
>> Deoptimization::Action_make_not_entrant);
>> }
>> ..
>> Here the control is being modified by set_control even though a bailout is possible afterwards.
>> Moving the set_control later in the intrinsic fixes this.
>>
>> This is a small fix. Please review.
>>
>> Best Regards,
>> Sandhya
>
> src/hotspot/share/opto/library_call.cpp line 1049:
>
>> 1047: record_for_igvn(rc);
>> 1048: }
>> 1049: set_control(_gvn.transform(new IfTrueNode(rc)));
>
> Or you can move `stopped()` check here (after `set_control()`) and avoid generation of useless `false` path.
Thanks @vnkozlov for the review. It is this set_control() that is resulting in an assert that control is changed but the intrinsic bailed out. Moving the stopped check right before set_control() would fix the issue. I will update the patch accordingly.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3958
More information about the hotspot-compiler-dev
mailing list