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
Tobias
More information about the hotspot-compiler-dev
mailing list