8000 Another Compaction Bug (Sorry) · Issue #1909 · calyxir/calyx · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
Another Compaction Bug (Sorry) #1909
Closed
@calebmkim

Description

@calebmkim

I just realized my fix for #1852 still leaves another bug.

Suppose we have a component foo that is @promotable

component foo (@promotable(4) @go go, ...) -> (...)

If we compact the following seq

@promotable(5) seq {
  @promotable(4) invoke foo()().
  @promotable(1) write_to_reg;
}

this means that we need foo to be static, since compaction involves taking @promotable -> static<n> control. (Also, any components that foo instantiates now also need to be promoted to static).
However, the decision to make foo--or any other component--static doesn't happen until the static-promotion pass, which runs after compaction. There's nothing in the promotion pass that forces foo to be static.

Solution/Future Direction

  1. One solution could be to merge compaction and promotion passes, since they are philisophically doing the same thing (converting dynamic code to static code). One reason why I don't think this is actually too bad is that most of the analysis in the compaction pass is externalized to analyses. In fact, if you look at the code of the finish_seq function for both compaction and promotion, there are actually some similarities: they basically iterate thru the existing seq, but the actual conversion of the seq to static control is outsourced to a separate function.

  2. Another solution is, in the compaction pass, to keep a list of all the components we have committed to promotion (i.e., all the components whose go port was written to in a seq that we compacted). At the end, we attach an attribute to all the components that must be static, and the promotion pass must promote them. This will lead to more aggressive promotion than before.

I'm still not 100% sure which solution is better, so I'd be happy to hear other people's thoughts.

Either way, there’s still the overall question of how to apply the promotion heuristics. I propose that, long-term, there should be some sort of universal promotion heuristic that applies to both compaction and promotion, while in the short term, we apply compaction aggressively (that is what we are doing currently), while performing generic promotion based on the heuristics.

Metadata

Metadata

Assignees

Labels

C: calyx-optOptimization or analysis passType: BugBug in the implementation

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0