RFC: C2: Anti-dependence on a load with a control in presence of a membar
vladimir.x.ivanov at oracle.com
Fri Mar 2 14:47:45 UTC 2018
I'm seeing unschedulable graph being produced during GCM when adding
anti-dependence to a load node with a control dependency. I found the
root cause, but can't decide how to fix it.
Here are steps which lead to the broken graph:
(1) The load causing problems (#391) is added as part of specializing
ArrayCopy for small arrays (added as part of JDK-6912521  in 9). Both
control & memory are tied to AllocateArray. (IR )
(2) EA proves that AllocateArray (#363, destination) is scalar
replaceable and during split_unique_types() updates corresponding
MemoryMerge (#379) and it allows to directly use memory produced by
ArrayCopy (#255, source) bypassing the allocation & membar (#348). (IR )
(3) After allocation elimination, the load control dependency is
switched to MemBarCPUOrder (#348) which was immediate dominator of
eliminated allocation (IR )
(4) After matching the load has control on the membar, but not memory
(IR before  and after  matching.)
(5) During GCM, anti-dependence from membar (#317) to the load is
added, but it makes the graph unschedulable which then triggers the
assertion  during LCM.
Relevant places in the code: 
Everything looks fine, except updates of MergeMems in step #2:
* the load is pinned to the proper branch after deciding what
direction to go;
* wide membars do need anti-dependences on loads
So, as a fix I'd disable memory edge updates which bypass any membars.
Does it sound reasonable or am I missing something important?
# Internal Error
# assert(false) failed: graph should be schedulable
More information about the hotspot-compiler-dev