[8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated
Tobias Hartmann
tobias.hartmann at oracle.com
Fri May 20 06:35:28 UTC 2016
Hi Vladimir,
thanks a lot for fixing this!
On 19.05.2016 19:45, 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!
> 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?
> Also, fixed a couple of missing cases in 8u (not applicable in 9):
> * CastII nodes shouldn't be eliminated during CCP pass;
> * CastII comparion should take _range_check_dependency flag into account.
Thanks, I missed this in the backport because the code is different in 9.
Best regards,
Tobias
>
> Testing:
> * JPRT (8u/9);
> * RBT for 9 (hs-tier0-comp - in progress);
> * replay of problematic compilation (8u).
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
More information about the hotspot-compiler-dev
mailing list