Reorder Compaction

[calebmkim]

Inserts compaction pass in between inference and promotion. This means that compaction takes @promote_static blocks of code and converts them to static<n> blocks.

Right now the "heuristic" is quite basic: it converts to static<n> for any seq block that it can compact at all (i.e., the new schedule is at least one cycle shorter than the original schedule).

[rachitnigam]

Right now the "heuristic" is quite basic: it converts to static for any seq block that it can compact at all (i.e., the new schedule is at least one cycle shorter than the original schedule).

How does this impact the heuristic defined for promotion? Should we eventually define a threshold for compaction also? Seems like this threshold business might get out of hand soon 😅

[calebmkim]

How does this impact the heuristic defined for promotion? Should we eventually define a threshold for compaction also? Seems like this threshold business might get out of hand soon 😅

Yeah, I think there are a few points here.

1. This change could increase promotion opportunities by affecting the control program that the promotion pass sees (see example here).

2. One thought I had, which goes hand in hand with Decouple aliases from pass names #1874: it may be useful to define "universal promotion heuristics" that we can apply to both compaction and promotion passes.

¹

Footnotes

1. One nitty-gritty detail, that I'm mostly have here for my own reference: for the "size threshold" parameter of static promotion, we count any static control block basically as a leaf (i..e, it has the same "size'' as a group enable or an invoke would). The reason for this is, when we measure "size threshold" as a heuristic, we really want to know "if we promote this block, how many times are we switching from the static calling convention to the dynamic calling convention?" If it is greater than threshold, then this will make up for the overhead of instantiating the fsm and wrapper logic. Because static control statements are already committed to using the static calling convention, it didn't really make sense to count their size as anything more than a group enable or an invoke. But for control programs were originally dynamic, then maybe it does make sense to count their children in the sizes, i.e., a compacted par with 12 groups in it as children should count as size 12, not 1. ↩

[rachitnigam]

universal promotion heuristics

I really like this idea! This can either be a compilation pipeline-level configuration that can be queried by various compiler passes or an analysis of some form. The former idea (compilation-level configuration) seems like a generally useful thing to have; many compiler passes may want to query the same oracle about how to make decisions. Centralizing this configuration somewhere would make maintaining and debugging it much easier!