[14] RFR(S): 8228772: C2 compilation fails due to unschedulable graph if DominatorSearchLimit is reached

[Tobias Hartmann]

Hi Nils,

On 31.07.19 11:21, Nils Eliasson wrote:
> Your patch looks good, and I seek no change to the patch, but I would like to take the opportunity
> to gain some additional insight.

Thanks for the review!

> Doesn't the memory graph look a bit strange? If the load is control dependent on the membar, and the
> membar creates a new memory state, shouldn't the load actually use that state?

Yes, that's the case before EA:
http://cr.openjdk.java.net/~thartmann/8228772/8228772_graph_before_EA.png

But once EA figures out that the array allocation does not escape, it creates a memory Phi for that
slice (6006), and re-wires the load to use that memory:
http://cr.openjdk.java.net/~thartmann/8228772/8228772_graph_after_EA.png

I think the code that does this is ConnectionGraph::find_inst_mem which steps through membars.

> The basic assumption is that for all memory ops using the same memory state, all loads must precede
> any store. This case breaks that. We should investigate why the IR ends up like this and if it is
> actually correct.

Right. Semantically, the IR seems correct to me though.

Best regards,
Tobias