[15] RFR(S): 8238178: CTW: C1 compilation fails with assert(sux->loop_depth() != block->loop_depth() || sux->loop_index() == block->loop_index() || loop_through_xhandler) failed: Loop index has to be same

[Tobias Hartmann]

Hi Christian,

this looks good to me. Nice test cases!

An additional review would be good, I don't think "S" is justified :D

Best regards,
Tobias

On 07.02.20 11:42, Christian Hagedorn wrote:
> Hi
> 
> Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8238178
> http://cr.openjdk.java.net/~chagedorn/8238178/webrev.00/
> 
> The failing assertion is part of the verification of the IR and states that a successor of a block
> must always have either the same loop index (as part of the same loop) or a different loop depth
> when exiting the loop. The latter condition is usually true since an edge to an immediately
> following loop header block is split and a new block inserted (with loop depth 0). However, if there
> is a loop that is only executed once on the non-exceptional path but multiple times in case of an
> exception, the edge is not split and another loop header block could immediately follow (as in the
> test cases). The loop_through_xhandler variable [1] should cover those cases in the assertion: If a
> successor of a loop head block 'h' is also a loop head block then the backbranch from 'h' must come
> from one of its exception handlers.
> 
> The current code assumes that the block from the backbranch is either an exception handler from the
> loop head block (as in testSimple()) or is dominated by an exception handler of the loop head block
> (as in testDominatedByXhandler()). However, this does not cover the case with additional try/catch
> blocks in a catch block such that the backbranch block is not dominated by any exception handler of
> the loop head block. For example in [2] (testNestedExceptions()), B5 and B17 have different loop
> indices and the same depth but B16 is neither dominated by xhandler B1 nor xhandler B2, letting the
> assertion fail.
> 
> The fix searches through all blocks in the loop to find an exception handler of the loop header block.
> 
> 
> Thank you!
> 
> Best regards,
> Christian
> 
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/5e402c63694f/src/hotspot/share/c1/c1_RangeCheckElimination.cpp#l1109
> 
> [2] https://bugs.openjdk.java.net/secure/attachment/86667/nested_exceptions.png