in our experiment, the execution is stuck at function `zend_cfg_identify_loops`

Nice find! Here's a somewhat reduced version:

<?php
function test($a, $b) {
    echo "Start\n";
    do {
        $i++;
        try {
           continue;
        } catch (Exception $e) {
        }   
        do { 
           $j++;
        } while ($j < $b);
    } while ($i < $a);
    echo "Done\n";
}
test();

CFG for reference: https://gist.github.com/nikic/84d11192df4d7b6cc42f971c7d15920b

The core problem here is that BB5 and BB6 are not reachable from entry through normal edges (they have domtree level 0 and will be processed last). They are reachable in the reverse graph though, which is traversed when loop headers are assigned. We end up with BB3 having BB6 as loop header, and BB6 having BB3 as loop header, causing an infinite loop.

There's probably two separate problems here: We should be treating unreachable code more gracefully, and we should not be treating this code as unreachable in the first place, though I'm not sure what the right way to handle unwind edges would be right now.

Though it would be great if we could not run loop identification in the first place if a function has try/catch. In that case we don't perform SSA construction or register allocation, which need this for correctness. It seems like the only places that use the information in that case is timeout checks and hot loop counters. Maybe we just want to pessimize those in the presence of try/catch?

Possible patch to avoid infinite loop: https://gist.github.com/nikic/072a365f6fe2f07e523757de0eb6c61f

It uses missing idom to identify blocks that are unreachable or only abnormally reachable and skips the loop header assignment for them.

Of course, that doesn't fix the problem that computed results for try/catch may be incorrect, as we're working on an inaccurate CFG.