RFR(S): 8228772: C2 compilation fails due to unschedulable graph if DominatorSearchLimit is reached
tobias.hartmann at oracle.com
Mon Aug 5 07:25:50 UTC 2019
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:
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:
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.
More information about the hotspot-compiler-dev