Studying effects of heuristics in passes

[rachitnigam]

For the Calyx 2.0 paper, I think it would be cool to study the effects of heuristics on the quality of results. Couple of things off the top of my head:

• [ ] Heuristics for inlining
• [ ] Breaking up FSMs in the style of new_fsm
• [ ] How to split up control programs in mixed dynamic-static cases (#1439)
• [ ] Sharing heuristics (from @calebmkim's PLDI SRC paper)
• [x] Effect from @data annotations (#1456)
• [ ] Effect of dynamic to static transformation (#1439)

I think having a good study and defaults for heuristics in the compiler moves us that much closer to a serious competitive baseline.

[calebmkim]

I've been thinking about

2. Breaking up FSMs in the style of new_fsm

There's one pretty easy way to do this: We can just compile static seq { @new_fsm *control1* @new_fsm *control2*} into something like seq { static_group1; static_group2; } in static-inliner, rather than compiling into a single group. When compile-static sees this code, it could handle it, but it would "waste" a cycle between static_group1 and static_group2.

I think there's probably a better way to compile it so that we don't waste a cycle in between groups. Specifically, I don't think the compile-static pass should force all static control to be compiled into a single enable, i.e., it should be able to handle something like static seq { static_group1; static_group2; }.