138d90eb73
There are now no known cases where the compiler package computes a stack depth lower than the one computed by the builtin compiler. (To achieve this state, we had to fix bugs in both compilers :-). The chief change is to do the depth calculations with respect to basic blocks. The stack effect of block is calculated. Then the flow graph is traversed using breadth-first search to find the max weight path through the graph. Had to fix the StackDepthTracker to calculate the right info for several opcodes: LOAD_ATTR, CALL_FUNCTION (and friends), MAKE_CLOSURE, and DUP_TOPX. XXX Still need to handle free variables in MAKE_CLOSURE. XXX There are still a lot of places where the computed stack depth is larger than for the builtin compiler. These won't cause the interpreter to overflow the frame, but they waste space. |
||
---|---|---|
.. | ||
__init__.py | ||
ast.py | ||
consts.py | ||
future.py | ||
misc.py | ||
pyassem.py | ||
pycodegen.py | ||
symbols.py | ||
syntax.py | ||
transformer.py | ||
visitor.py |