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