[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    Re: RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here
From:       Vladimir Kozlov <vladimir.kozlov () oracle ! com>
Date:       2018-06-29 18:35:05
Message-ID: 5af5a8d9-b6e0-e072-7b6b-bd0f01661795 () oracle ! com
[Download RAW message or body]

Tobias already started testing and I see new crashes. It was Kitchensink 
test running with ZGC.

#  Internal Error 
(/scratch/workspace/open/src/hotspot/share/opto/loopnode.cpp:3826), 
pid=1305, tid=1382
#  assert(!had_error) failed: bad dominance

Current CompileTask:
C2: 910563 14019       4       org.sunflow.core.ParameterList::clear (96 
bytes)

V  [libjvm.so+0xb4e310]  report_vm_error(char const*, int, char const*, 
char const*, ...)+0x100
V  [libjvm.so+0x128b3cb]  PhaseIdealLoop::compute_lca_of_uses(Node*, 
Node*, bool)+0x32b

I attached output and hs_err to bug report.

Vladimir

On 6/29/18 11:00 AM, Vladimir Kozlov wrote:
> Thank you, Roland
> 
> Explanation and changes seems reasonable. Let me test it.
> 
> Thanks,
> Vladimir
> 
> On 6/29/18 1:14 AM, Roland Westrelin wrote:
>>
>> Hi Vladimir,
>>
>>> Looks like this change cause an other crash for example in
>>> gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed
>>> - only ones in the test)
>>
>> Thanks for testing. Here is an updated webrev:
>>
>> http://cr.openjdk.java.net/~roland/8205515/webrev.01/
>>
>> We have a block of regular predicates, followed by a block of profile
>> predicates. For a data node that's above a loop, the logic tries to set
>> its control as high as possible above the predicates.
>>
>> The current logic looks for the profile predicate added at parse time
>> then possibly for the predicate added at parse time and set the control
>> of the data node above.
>>
>> So with:
>>
>> predicate added at parse time (with Opaque1 node)
>>
>> profile predicate added at parse time (with Opaque1 node)
>>
>> the data node would have control set above both predicates. With:
>>
>> some predicate hoisted by loop predication
>> some predicate hoisted by loop predication
>> predicate added at parse time (with Opaque1 node)
>>
>> profile predicate added at parse time (with Opaque1 node)
>>
>> the data node would have control set right above the predicate added at
>> parse time. And with:
>>
>> some predicate hoisted by loop predication
>> some predicate hoisted by loop predication
>> predicate added at parse time (with Opaque1 node)
>>
>> some profile predicate hoisted by loop predication
>> some profile predicate hoisted by loop predication
>> profile predicate added at parse time (with Opaque1 node)
>>
>> the data node have control set right above the profile predicate added
>> at parse time.
>>
>> The problem is that sometimes, we have something like:
>>
>> predicate added at parse time (with Opaque1 node)
>>
>> if (a == null) { unc; } //some predicate hoisted by loop predication
>> a = cast_not_null(a);     //data node control   dependent on hoisted 
>> predicate
>> profile predicate added at parse time (with Opaque1 node)
>>
>> then the compiler finds a dominating if (a == null) checks so the
>> predicate can be removed but dominated_by() prevents the cast from
>> moving up:
>>
>> predicate added at parse time (with Opaque1 node)
>>
>> a = cast_not_null(a);
>>
>> profile predicate added at parse time (with Opaque1 node)
>>
>> The current logic tries to set control of the cast above the first
>> predicate which is incorrect.
>>
>> Roland.
>>
[prev in list] [next in list] [prev in thread] [next in thread]