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

[Nils Eliasson]

On 2019-08-05 09:25, Tobias Hartmann wrote:
> 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.

ok, but then the store and the load doesn't alias, and no 
anti-dependence edge is actually needed. Perhaps that info isn't handled 
correctly by the anti-dep-checker. That is something we need to revisit 
for 14.

// N


>
>> 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