To-Do Tasks for Static Groups

[calebmkim]

Overall Sketch for the Dates/Goals of this Project

Compiler Tasks

• Finish the static-inlining stuff by 5/1. This will allow us to compile the "static islands" into a single static group, which can then be turned into a dynamic group using the compile-static pass we've already created.
• Giving the static-inlining more opportunities to work. This includes: a) "group promotion": inferring the static latency of dynamic groups and turning them into static groups. b) "control promotion": turning dynamic control operators that contain static groups into static control operators. E.g., seq { static_foo; static_bar; dyn_baz } to seq { static seq { static_foo; static_bar }; dyn_baz }. c) "control rearrangement" rearranging the control operators to improve the hardware (e.g., something like static-par-conv or merge-static-par. We should think about if these will actually be helpful for the static inlining + compile static pass, though.
• Allow other passes to use static information to improve: e.g., live range analysis & sharing can use static information.
• Potential new passes: "auto parallelization". Potentially instantiate new hardware in order to find increased parallelization opportunities in the design. register-unsharing pass can be a helpful starting point.
  Frontend Tasks
• CIRCT
• Other potential frontends: PolySA, HeteroCL, SpMV.
• We should probably work on the frontends after we've done the basics of the static compilation and optimizations (static inlining, group + control promotion) but before we do the more advanced optimizations (e..g, "auto-parllalization).

CONCRETE TO-DOS

A tracker for the "to-do" tasks for Static Groups. Some are definitely bigger than others, and we should probably add issues as they come up. Right now, this is just a preliminary list. @paili0628 feel free to add more in case I forgot any.
Note that much of the existing code will break once we turn the assignments field of static groups from assignments type -> static_assignment type, which is something we are keeping in mind.

Shorter Term (to do once we get the IR fully formed)

• Passes that visit Enables might want to visit StatcEnables. This is a case by case basis, but some of the passes that apply operations to groups should apply them to static groups as well
• There is some code duplication in LiveRangeAnalysis, Well Formed, and Reaching Definitions. Once we get the IR fully figured out, we should figure out the best way to reduce this duplicate code.
• Add a latency field for static groups
• Rewrite the MergeStaticPar and StaticParConv passes to operate on static groups (once we have defined latency fields). Also, CollapseControl should work on static pars/seqs.
• group2invoke should handle static groups. But we first need to define StaticInvoke + other static control in the IR.
• group2seq is weird w/ static groups. How do we infer the latency of the split groups? We can leave it to infer-static-timing, but then, would that mean turning the static groups into 2 non-static groups?...
• Possibly create aliases for Guard<StaticTiming> into something like StaticGuard, Assignment<StaticTiming> into StaticAssignment.
• Turn Nothing into (). The main thing is getting pretty printing right.
• compute_static should be fundamentally changed to turn regular control into static control when possible. Rn it just adds attributes, but we want to do more ideally.

Longer Term (to do once we implement static groups correctly)

• Python Library (and other frontends) should be rewritten
• We should change infer-static-timing to change groups -> static groups, instead of adding an attribute

[paili0628]

• (longer term) The compile-sync pass does not take in static control now. We need to figure out what type of synchronization we want for static control.
• (shorter term) We want to get rid of the StaticEnable variant in Control enum
• (shorter term) Make collapse-control pass handle static groups. If static repeat has an iteration number of 0 to 1, then collapse it to the inner body or empty

[sampsyo]

Sounds good overall! One thing I don't 100% understand: what's the motivation for getting rid of StaticEnable? Just curious; it probably doesn't matter too much.

[paili0628]

Oh that's just because we decided that all static control should be under one variant static, which itself holds an enum. But before that we already added the StaticEnable variant separately, which we have to delete now but we might have things to fix once we've done that.

[sampsyo]

Ah, that makes sense!! Cool!!!

[rachitnigam]

group2seq is weird w/ static groups. How do we infer the latency of the split groups? We can leave it to infer-static-timing, but then, would that mean turning the static groups into 2 non-static groups?...

We've decided to not split apart static groups since its just the inverse transform of static inline

[rachitnigam]

group2seq is weird w/ static groups. How do we infer the latency of the split groups? We can leave it to infer-static-timing, but then, would that mean turning the static groups into 2 non-static groups?...

We've decided to not split apart static groups since its just the inverse transform of static inline

[rachitnigam]

Once we're done with the Static groups milestone, we'll go over this again and create issues from all the relevant bullet points and close this tracker

[rachitnigam]

@calebmkim @paili0628 can y'all go over this and update it?