Improve Static FSM Compilation

[calebmkim]

Implements the ideas from #2207.

Apologies for the gigantic PR, there are a couple reasons why it is so big:

1. It represents a big change in the compiler
2. I didn't know if it was going to even be worth it to implement these changes to the compiler, so I implemented some improvements to the compilation process that complicated the code (but improved results).

There are some minor changes to static_inline.rs (in particular, inlining static par blocks is more complicated now because we can't merge always just merge all threads of a static par into the same group). There are some changes to compile_static.rs, but the main contribution of this PR is the file static_tree.rs.

I'm still going to write some tests to make sure I'm getting all edge cases for this new tree-looking FSM compilation.

[rachitnigam]

Hm, these tests are too big and probably never actually checked. @nathanielnrn is there a game plan to eventually deprecate them (nothing for @calebmkim to do on this in this PR).

[rachitnigam]

Hey @calebmkim, can we get this PR in a mergeable state soon? I'm assuming this is the PR that adds the code that needs to be handed off to @parthsarkar17?

[calebmkim]

Yep; I think I just need to add a few extra test cases, let @parthsarkar17 look over the code (if he wants and ask questions) and I think it'll be pretty close to mergeable. (I will add the test cases within the next couple of days)

[calebmkim]

There’s a lot in this PR: the main files to look at (in decreasing order of importance) are: analysis/static_tree.rs, passes/compile_static.rs/passes/static_inliner.rs, and passes/static_fsm.rs

The code is quite complex. While some of this is “necessary complexity”, i.e., can be explained by the fact that we are just generating more complicated guards/wiring now. Here are some other sources of code complexity:

• There is an awkward dependency between the static-inliner and compile-static passes: for example, the “pause when offloading” behavior is a parameter for both passes: it must be set to the same for both passes for compilation to work (e.g., if you tell static-inliner to pause when offloading, then you also have to tell compile-static to pause when offloading, otherwise compilation will not work properly). Also, the compile-static pass builds the tree structure by recovering the control flow by looking at static_body[go] %[i:j] ? 1'd1 assignments; ideally the tree would be created by the static-inliner pass and then passed to the compile-static pass.
• There’s lots of metadata (e.g., about which fsms handle which groups) that needs to be passed into functions so that the compile-static pass knows how to build wrappers, rename control, etc. While there is a struct devoted to expressing a tree, it's possible that there should be yet another struct to describe a collection of trees that could potentially share FSMs. Right now this is being done by the compile-static pass but the code looks a bit messy.
• We handle static component differently than static group. In particular, the 0->1 transition of static component must be guarded by the component’s go signal. This is because we only want some assignments to be guarded by component.go for static components, rather than dynamic components, in which all assignments are guarded by component.go. This may be worth it for performance, but it’s a bit of a pain to handle when writing code.
• In static-inliner the code to determine when we can merge threads is surprisingly complex. I suspect we may be able to do something better if we somehow were able to merge the static-inliner and compile-static passes.

I think that once we merge this, it would be good for someone (maybe me) to do another iteration on this code and just clean it up a bit. I'm hesitant to do so in this PR because it will add yet more code to an already gigantic PR.

[rachitnigam]

@calebmkim thought on what the state of this PR is? We should get this merged before OOPSLA in case people end up playing with it afterwards.

[calebmkim]

So there are some places where the code is perhaps more awkward/more verbose than it needs to be, but I also left a lot of comments in the code explaining (in detail) the decisions, so I think it should be decently readable for whoever works on this after me.

I think it's probably fine to merge, though?

[rachitnigam]

Sounds good! Merging!