gh-92782: unify the style of CFG traversal algorithms in the compiler

[iritkatriel]

This makes the traversals more consistent:

• reduces repetition of stack allocation code
• makes them all use PyMem_Malloc (currently there are two that use PyObject_Malloc)
• always counts the blocks (a.a_nblocks can be stale) and uses the b_next list, which excludes unreachable (empty) blocks
• always initialises b_visited before a traversal
• mark_reachable uses b_visited
• eliminate_empty_basic_blocks fixes except targets like jump targets (see discussion below)

[iritkatriel]

The test failure seems to imply that in a subprocess we can end up calling mark_reachable multiple times on the same code. Is this expected?

[iritkatriel]

I can't reproduce that test failure on my machine, so I'm reverting that particular change.

[sweeneyde]

These changes look correct to me, though I have a slightly-off-topic question:

When traversing via b = b->b_next, how is it ensured that exception handlers stay in that linked list? Can empty exception handlers exist? If so, can they get removed by eliminate_empty_basic_blocks and then leave connected basicblocks dangling?

[iritkatriel]

When traversing via b = b->b_next, how is it ensured that exception handlers stay in that linked list? Can empty exception handlers exist? If so, can they get removed by eliminate_empty_basic_blocks and then leave connected basicblocks dangling?

I think you're right that eliminate_empty_basic_blocks should fix targets of block_push instructions in the same way that it does for jumps.

I think we're getting away with this at the moment the first block of the handler always has a PUSH_EXC_INFO instruction, so it's never empty.

[iritkatriel]

I believe I found out why making mark_reachable use b_visited failed.

It is currently possible to get a conditional jump to the next block. So b_next == b_target, and my assertion assumed this is not the case.

I've updated the assertion and put that change back in this PR. We'll see what the buildbots think.

[iritkatriel]

@markshannon I think this is ready to be merged. Last chance to object review.

[markshannon]

No objections. LGTM.