[8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri May 20 11:57:36 UTC 2016


>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/
>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/
>> https://bugs.openjdk.java.net/browse/JDK-8154831
>
> Looks good to me!

Thanks, Tobias.

>> CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region).
>>
>> CastII is replaced with TOP due to a type conflict (ranges don't intersect) between the actual type of the value being range checked and the type CastII tries to assign.
>>
>> It happens on effectively dead path (range check always fails) which C2 can't eliminate due to a missing transformation for CmpU:
>>
>>    Bool [lt] (CmpU (ConI #-1) (… #int)) => (ConI #0)
>>
>> The fix is to add the missing case in CmpUNode::sub(). It enables dead path elimination along with CastII.
>
> We discussed this already offline but I still wonder if it can happen that even if we would eliminate the range check, we replace the CastII first (due to IGVN ordering) and crash before the range check is eliminated?

I verified that the ordering is not a problem. If both range check and 
dependent CastII/ConvI2L nodes go away during the same IGVN pass, then 
the compiler encounters correct graph on the next iteration of loop 
optimization pass.

Best regards,
Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list