Mark Shannon <m...@hotpy.org> added the comment: On 01/01/18 17:54, Antoine Pitrou wrote: > > Antoine Pitrou <pit...@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 <rep...@bugs.python.org> > <https://bugs.python.org/issue17611> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com