[16] RFR(M): 8249607: C2: assert(!had_error) failed: bad dominance

[Roland Westrelin]

Hi Christian,

> We have two options to fix this. We could either update the wrong 
> control inputs from 876 IfFalse during the creation/merging of 
> pre/main/post loops or directly fix it inside 
> split_if_with_blocks_post(). I think it is makes more sense and is also 
> easier to directly fix it in split_if_with_blocks_post() where we could 
> be less pessimistic when pinning loads.
>
> The fix now checks if late_load_ctrl is a loop exit of a loop that has 
> an outer strip mined loop and if it dominates x_ctrl. If that is the 
> case, we use the outer loop exit control instead. This also means that 
> the loads can completely float out of the outer strip mined loop. 
> Applying that to the testcase, we get [3] instead of [2]. LoadS 901 and 
> 902 are both at the outer strip mined loop exit while 903 LoadS is still 
> at the inner loop due to 575 StoreI (x_ctrl is 876 IfFalse and dominates 
> the outer strip mined loop exit). The process of creating pre/main/post 
> loops will then take care of these control inputs of the LoadSNodes and 
> rewires them to the newly created RegionNode such that the dominator 
> information is correct again.

I agree that fixing it in split_if_with_blocks_post() is the right thing
to do.

The load has no edges to the safepoint in the outer strip mined loop so
why is it in the loop in the first place then? If java code has a load
in a loop that's live outside the loop then it should be live at the
safepoint on loop exit. Is anti dependence analysis too conservative?

Also why does get_late_ctrl(n, n_ctrl) return a control inside the outer
strip mined loop? And why is it safe to bypass that result?

Roland.