Perform dataflow analysis in the bytecode compiler #306
Replies: 13 comments 10 replies
-
This is basically impossible with the compiler in its current form. |
Beta Was this translation helpful? Give feedback.
-
So the bytecode would be converted into SSA form, optimised, and then converted back into stack-machine bytecode? Or what exactly are you proposing? |
Beta Was this translation helpful? Give feedback.
-
The IR is stack based, but it isn't bytecode. |
Beta Was this translation helpful? Give feedback.
-
Something like that. |
Beta Was this translation helpful? Give feedback.
-
I think we can get a first level of liveness analysis with a hundred or so lines of code, without transforming everything into SSA, by just walking through the graph of basic blocks and marking things as "unsafe" when it's possible that they haven't been initialized yet. I have a branch here that has all tests passing, except I have yet to deal with the debugger situation, but I was thinking it could convert every |
Beta Was this translation helpful? Give feedback.
-
PyPerformance somehow got "Geometric mean: 1.01x slower" for me
|
Beta Was this translation helpful? Give feedback.
-
NULL checks are cheap: it is a perfectly predicted branch, testing a value that it is in a register. So I'm not surprised the difference in performance is negligible. Also, I don't think removing the NULL check is safe. Potentially, someone could delete a local in the debugger. |
Beta Was this translation helpful? Give feedback.
-
I ran pyperformance 3 times on main, 3 times on the branch with the https://gist.github.com/sweeneyde/32b69bea8f7e15df7bbd9c41eac85f8d |
Beta Was this translation helpful? Give feedback.
-
Rather than add a |
Beta Was this translation helpful? Give feedback.
-
With regard to your draft implementation. 99.9% fewer NULL checks is excellent. Regarding removal of the
|
Beta Was this translation helpful? Give feedback.
-
We could do something like python/cpython#93144 for stores. From analysis, we should know (for most cases at least) whether the variable was
This would convert one instruction into three, and would negatively impact the superinstructions, so it isn't clear that it would be worthwhile. |
Beta Was this translation helpful? Give feedback.
-
Thanks for trying that out. I think we'll leave loop peeling for the higher tier optimizers (it happens implicitly if the VM is looking for hot backedges). |
Beta Was this translation helpful? Give feedback.
-
There a number of standard compiler analyses that we could implement and would be useful. For example:
Since the 1990s, the conventional way to perform these, and many other, analyses has been SSA form.
SSA form is a bit intimidating to start with, but once you are used to it, it seems natural and easy to work with.
Dataflow analysis would allow us to do less work handling variables and the stack, avoiding some NULL checks.
For example:
LOAD_FAST
will not need a NULL check as the compiler can detect if the variable can be undefined (and insert a check in the rare case that it is necessary)By themselves, these changes might not justify the extra complexity in the compiler, but combined with the refcount improvements in #308, it might.
We would need to take care when modifying local variables in the debugger.
We might have to accept some rare memory leaks, and disallow deletion of local variables (assigning
None
instead).Beta Was this translation helpful? Give feedback.
All reactions