[issue26549] co_stacksize is calculated from unoptimized code

[STINNER Victor]

STINNER Victor  added the comment:

> Seems moving constant folding to the AST level (issue29469) have solved this 
> issue.

Wow, it's cool to see this bug finally fixed!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Seems moving constant folding to the AST level (issue29469) have solved this 
issue.

>>> def foo():
... a = (1,2,3,4,5,6,7,8,9,10)
... 
>>> foo.__code__.co_stacksize
1

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> AST-level Constant folding

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[STINNER Victor]

Changes by STINNER Victor :


--
type:  -> performance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Meador Inge]

Meador Inge added the comment:

See also issue24340

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Meador Inge]

Meador Inge added the comment:

Strictly speaking, the stack size is calculated *after* the peephole optimizer 
is run, but the code that computes the stack depth operates on the basic block 
graph instead of the assembled and optimized byte code.

Anyway, the conclusion is the same as Brett noted -- the stack depth analysis 
would need to be re-written to operate on the optimized bytecode array.

--
nosy: +meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Jelle Zijlstra]

Jelle Zijlstra added the comment:

This also affects co_consts, which includes constants that are no longer used 
by the optimized code:

In [8]: def f():
return (1, 2, 3, 4, 5)
   ...: 

In [9]: f.func_code.co_consts
Out[9]: (None, 1, 2, 3, 4, 5, (1, 2, 3, 4, 5))

In [12]: dis.dis(f)
  2   0 LOAD_CONST   6 ((1, 2, 3, 4, 5))
  3 RETURN_VALUE

--
nosy: +Jelle Zijlstra

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Brett Cannon]

Brett Cannon added the comment:

I also suspect you're right, Antti, that the stack size is calculated prior to 
the bytecode being passed to through the peepholer which would have made the 
built tuple a value in the const array.

Off the top of my head I don't remember where the stack size calculation is 
made, but my suspicion is it's in the AT -> bytecode step, which would mean 
making it work from bytecode would mean re-implementing that calculation to 
work from the bytecode itself (assuming I'm right).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[SilentGhost]

Changes by SilentGhost :


--
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26549] co_stacksize is calculated from unoptimized code

[Antti Haapala]

New submission from Antti Haapala:

When answering a question on StackOverflow, I noticed that a function that only 
loads a constant tuple to a local variable still has a large `co_stacksize` as 
if it was built with BUILD_TUPLE.

e.g.

>>> def foo():
... a = (1,2,3,4,5,6,7,8,9,10)
...
>>> foo.__code__.co_stacksize
10
>>> dis.dis(foo)
  2   0 LOAD_CONST  11 ((1, 2, 3, 4, 5, 6, 7, 8, 9, 10))
  3 STORE_FAST   0 (a)
  6 LOAD_CONST   0 (None)
  9 RETURN_VALUE

I suspect it is because in the `makecode` the stack usage is calculated from 
the unoptimized assembler output instead of the actual optimized bytecode. I do 
not know if there is any optimization that would increase the stack usage, but 
perhaps it should be calculated from the resulting output.

--
components: Interpreter Core
messages: 261668
nosy: ztane
priority: normal
severity: normal
status: open
title: co_stacksize is calculated from unoptimized code
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com