Inefficient lowering in `static-inliner` pass

[calebmkim]

The current static-inliner pass works in a "bottom up" manner. The inline_static_control() function is the key inlining function here. To understand how it works, consider an example: static seq {stmt1; stmt2; stmt3;}. It will first compile stmt1, stmt2, and stmt3 into static groups by recursively calling inline_static_control() on each stmt. Then it will rewrite the assignments in each of the groups corresponding to stmt1, stmt2, and stmt3, before finally placing all of those assignments into a single static group (that represents the entire static seq) and returning that single static group.

An inefficiency comes in from the fact that if a static group is nested within $n$ levels of control, then its assignments will get rewritten $n$ times. (This is also why this pass generates redundant guards, and is the motivation behind the simplify-static-guards pass)

Ideally, we only would need to rewrite these assignments once (when turning the "static island" into a static group). This would require a "top down" approach. We should have some sort of data structure that maps groups to their appropriate "offset" (which is updated throughout the recursive calls to inline_static_control), and then, at the end when we're compiling the static island into a single static group, we should "realize" the offsets just once by rewriting the assignments.

One thing to note is that (after running simplify-static-guards) this shouldn't affect the performance of the compiled code; it's just inefficient for the compiler to keep on unnecessarily rewriting these assignments.

[sampsyo]

Nice recap! This makes sense to me. I know this isn't very important, but I think it would be kinda cool to keep the other approach (the current bottom-up inline) around even if we do make a better top-down pass, merely because it is easier to think about the incremental approach for correctness purposes.