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

Tobias Hartmann tobias.hartmann at oracle.com
Mon Jan 15 10:33:38 UTC 2018

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

More information about the hotspot-compiler-dev mailing list