RFR(S): 8201532: Update idom to get correct dom depth calculation

[Nils Eliasson]

On 2018-04-13 17:03, Roland Westrelin wrote:
>> What happens is that when the counted loop transformation replaces the
>> loop exit projections here
>> (http://hg.openjdk.java.net/jdk/hs/file/69bae761600b/src/hotspot/share/opto/loopnode.cpp#l728),
>> any recalculation of dom depth will continue to be wrong on the
>> successors. (Until the lazy mappings have propageted to the _idom.) If a
>> loadbarrier is moved out of the loop, or any other transformation is
>> performed that increases the loop depth, we may later fail in clone_loop
>> here
>> (http://hg.openjdk.java.net/jdk/hs/file/69bae761600b/src/hotspot/share/opto/loopopts.cpp#l2010)
>> when the new deeper dom depth of the loop is compared with the old doom
>> depth of the successor node.
> Wouldn't the generic fix be to call idom() from recompute_dom_depth()?
>
> There are very few calls to recompute_dom_depth() (2 actually: one for
> partial peel and one for loop unswitching). The usual practice when
> possible is to set the same dom depth for multiple control nodes
> (there's not need for a recompute_dom_depth() call then). So I suppose
> you could get rid of the extra recompute_dom_depth() calls in the zgc
> code.
>
> Roland.
Agree, I can remove the call at a few sites, but I might retain them in 
debug builds, so that we can still rely on asserts using dom_depths.

I did a version with recompute_dom_depth updating the _idom. I had to 
take a detour verifying that the check for dead-nodes in the idom was 
always correct at the recompute_dom_depth sites.

Webrev: http://cr.openjdk.java.net/~neliasso/8201532/webrev.03

//Nils