On 01/01/18 17:54, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> I took a quick look at Mark's PR.  The main thing going for it IMHO is that it produces simpler bytecode: it removes the complicated with/finally-related opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY.
> 
> It would be nice to know if it's able to fix the stack size issues as in the following tests:
> https://github.com/python/cpython/pull/5006/files?diff=unified#diff-dae68b96e8fdcb924e1ea46c31f51aec

Yes, it can. The key to determining a correct stack size is that each 
bytecode has a fixed stack delta for each exiting edge.
For example, FOR_ITER is good because it has a delta of 0 when entering 
the body and a delta of -1 when leaving the loop.
But (the old) WITH_CLEANUP_START is bad because it has a variable delta.

With fixed deltas, it is not too hard to construct an algorithm to 
determine the correct stack size. The presence of JSR-style finally 
blocks complicates things a little, but not that much.

An outline algorithm would be:
     Find all "finally" subgraphs, so as to distinguish them from the 
main CFG - It might be easiest to do this by marking the basic blocks 
where generating the code.
     For each subgraph compute max-depth, by keeping a running total of
     depth. Jumps to finally blocks should not alter the depth, but 
would potentially increase the max-depth.
     The max-depth for the main CFG is the stack depth for the function.

> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue17611>
> _______________________________________
>