RFR(S): 8229483: Sinking load out of loop may trigger: assert(found_sfpt) failed: no node in loop that's not input to safepoint

[Roland Westrelin]

http://cr.openjdk.java.net/~roland/8229483/webrev.00/

The field load in the test case has an early control right below:

barrier = 1;

(it's a volatile store)

and a late control that's conservatively set to be right above:

array[0] = j;

by anti dependence analysis.

The store array[0] is sunk out of the inner loop in the outer strip
mined loop right above the strip mined loop's safepoint. The load
initially scheduled in the outer loop is a candidate for being cloned
and sunk out of loop at the load usages. Because of the anti-dependence
with the array[0], it is sunk into the outer strip mined loop eventhough
it is not referenced by the safepoint. That breaks loop strip mining
verification because the expectation is that any data node in the outer
strip mined loop is there because it's referenced by the safepoint.

The fix simply recognizes this special case when the load is being sunk
out of loop and makes sure it is not moved in the outer strip mined
loop.

Unrelated to this fix, I wonder if the code at:

http://hg.openjdk.java.net/jdk/jdk/file/cb836bd08d58/src/hotspot/share/opto/loopopts.cpp#l1346

really does what the comment says it does for loads (and really does
anything useful actually).

Late control for the load is computed with:

late_load_ctrl = get_late_ctrl(n, n_ctrl);

to make sure anti dependences are taken into account. But if a load is
in a loop, it's because it has uses outside the loop. So late control
for the load is in the loop too. When sinking the load, the restriction
is that clones should not float below late control, then clones are
going to stay in the loop. And that code doesn't do anything for
loads. Or am I missing something?

Roland.