[14] RFR(S): 8233032: assert(in_bb(n)) failed: must be

[Christian Hagedorn]

Hi

Please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8233032
http://cr.openjdk.java.net/~chagedorn/8233032/webrev.00/

The problem of the bug can be traced back to finding the first and last 
memory state of a load when processing a load pack in 
SuperWord::co_locate_pack() [1]. One load of a load pack in the test 
case is dependent on the store node 's' which is sandwiched between 
other store nodes 'p1' and 'p2' of a store pack (p1 -> s -> p2). The 
other load of the load pack is dependent on the store node 'p2'. The 
sandwiched store node 's' swaps positions with 'p2' to move it out of 
the pack dependencies: p1 -> p2 -> s. However, the bb indices are not 
updated (bb_idx(s) < bb_idx(p2) is still true). Therefore, it sets 
last_mem to the memory state of the first load in the loop at [1]. As a 
result, the graph walk at [2] always starts following the input of the 
memory state of the first load (which should actually be the one of the 
last load) and will move beyond a loop phi as the stop condition is 
never met for a node having another memory state than the first one of 
the load pack. Eventually a bb index for a node outside of the loop is 
read resulting in the seen assertion failure.

I suggest to use a solution to look up the first and last memory state 
that does not use bb indices as it probably is quite difficult to update 
them properly when moving sandwiched stores around. I've seen that 
Roland once proposed such a solution [3][4] which he then replaced by a 
version using bb indices (causing this bug). I adopted Roland's original 
patch into mine and propose to use it as a fix.

Thank you!

Best regards,
Christian


[1] 
https://hg.openjdk.java.net/jdk/jdk/file/5defda391e18/src/hotspot/share/opto/superword.cpp#l2258
[2] 
https://hg.openjdk.java.net/jdk/jdk/file/5defda391e18/src/hotspot/share/opto/superword.cpp#l2276
[3] 
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-April/028702.html
[4] http://cr.openjdk.java.net/~roland/8201367/webrev.00/