Author Mark.Shannon
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent
Date 2018-01-02.09:32:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <34e0f2fa-9bc5-3fcd-d6e8-32d4aede09c6@hotpy.org>
In-reply-to <1514829251.29.0.467229070634.issue17611@psf.upfronthosting.co.za>
Content
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>
> _______________________________________
>
History
Date User Action Args
2018-01-02 09:32:39Mark.Shannonsetrecipients: + Mark.Shannon, nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, serhiy.storchaka, Demur Rumed
2018-01-02 09:32:38Mark.Shannonlinkissue17611 messages
2018-01-02 09:32:37Mark.Shannoncreate