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

Tobias Hartmann tobias.hartmann at oracle.com
Fri May 20 11:59:22 UTC 2016


Hi Vladimir,

On 20.05.2016 13:57, Vladimir Ivanov wrote:
>>> 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.

Okay, thanks for clarifying!

Best regards,
Tobias

> 
> Best regards,
> Vladimir Ivanov


More information about the hotspot-compiler-dev mailing list