Basic-blocks-based intermediate language and flow analysis. #607
Conversation
Changing to this order of traversal both on uninitialized.lua flow analysis and on constant_propagation.lua
The codebase should now have no trace of the previous tree-based i.r., only the new basic blocks i.r..
|
|
||
| -- Transform parent node | ||
| return f(cmd) or cmd | ||
| function ir.flatten_cmd(block_list) |
There was a problem hiding this comment.
I'm looking forward to deleting this flatten_cmd funciton. If I remember correctly, it only exists because of how we implement gc.lua: it uses the commands themselves as keys in the table.
There was a problem hiding this comment.
It can be removed now. I don't think the gc needs it, it uses the Cmd object itself as the table's key, not the index on flatten_cmd.
There was a problem hiding this comment.
I am also looking forward to getting rid of commands as table keys :) see #575
In a basic block world, the GC analysis should work with basic blocks indices aa the key.
There was a problem hiding this comment.
I'm working on changing the gc to use flow analysis. Should we wait to make this change of "get rid of cmds as keys" for another PR?
There was a problem hiding this comment.
It's ok to leave it for next PR (but in that case, please open an issue so we do not forget)
Changing the previous intermediate language, which was a tree, to a new one made out of a graph of basic blocks. This change is being made so it's easier to implement future optimizations for the generated code using standard flow analysis techniques. Here, we're already using flow analysis on the blocks to identify uninitialized variables.