RFR(M): 8193130: Bad graph when unrolled loop bounds conflicts with range checks

[Vladimir Kozlov]

First, I am suggesting to defer it to jdk 11 since it is present in jdk 
9 (not new in jdk 10) and the fix is not simple. It is just 6 months delay.

I want to look on it. Will do it after offsite meeting.

Thanks,
Vladimir

On 1/15/18 2:33 AM, Tobias Hartmann wrote:
> Hi Roland,
> 
> On 15.01.2018 10:18, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~roland/8193130/webrev.01/
> 
> Looks good to me but I think a second review is required here because the changes are complex.
> 
>>> compile.cpp
>>> - Why do you only remove the Opaque4Nodes after the macro expansion phase? Couldn't we avoid the additional
>>> igvn.optimize() by merging it into line 2346?
>>
>> Opaque1 nodes are only guaranteed to have been eliminated once macro
>> expansion is over. So the igvn that follows could still cause some of
>> the predicates I added on the main loop to make the path to the main
>> loop go dead. That's why elimination of Opaque4 nodes is delayed that
>> late.
> 
> Okay, thanks for the explanation.
> 
>>> loopPredicate.cpp
>>> - line 780: Why is that check necessary? And wouldn't it make more sense to check this in the caller?
>>
>> is_range_check_if() returns true for non RangeCheck nodes so there needs
>> to be a check for RangeCheck. I moved it into the caller.
> 
> Right, looks good.
> 
>>> Please update the copyright dates to 2018. Did you run any performance testing?
>>
>> I did eventhough I'm perplexed that we need to do that by hands. I took
>> care of all other comments as well.
> 
> Thanks Roland, I've basically meant the copyright date of the newly added test. But I guess you are right, copyright
> dates should be updated automatically at some point.
> 
> Best regards
> Tobias
>