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