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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu May 19 20:44:35 UTC 2016


On 5/19/16 1:29 PM, Vladimir Ivanov wrote:
> Thanks for the feedback, Vladimir.
>
>> Can you make subnode.cpp changes in jdk9 and 8u similar?
>
> Fixed. Updated webrev.9.00 in place.

Good.

>
>> Why CastIINode::cmp() returns uint?
>
> That's how Node::cmp() is declared:
>
>   virtual uint cmp( const Node &n ) const;

Please files starter RFE to fix it. I looked and result us used as bool.

Thanks,
Vladimir

>
> Best regards,
> Vladimir Ivanov
>
>> On 5/19/16 10:45 AM, 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
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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