Separate Inference and Promotion into Separate Passes

[calebmkim]

This is the first step of the progress described in here.

Apologies for the really big PR, but a lot of it is just moving around code and slightly changing tests.

The main new thing is the fixup_timing function. Suppose component B instantiates component A. Suppose also that we infer component's A's latency, and use that to infer the latency of B. If we decide not to promote A, then we can the inference information in B is no longer valid. This fixup_timing function should account for that. I wrote the function so that it can also (hopefully) be applied to compaction when we need to re-infer components after we compact them. There are tests for this behavior it here and here

[rachitnigam]

Awesome! BTW, the previous implementation of this kind of "fixup" logic is in WithStatic. We can remove it in a follow-up PR as we start getting rid of @static (#1429).

[calebmkim]

BTW, the previous implementation of this kind of "fixup" logic is in WithStatic.

Yeah, I actually use WithStatic already in the FixUp (I just changed the @static keyword to @promote_static). It's just that the FixUp also needed to remove and then re-infer the latencies of groups as well. Perhaps I can move that code to the inference_analysis.rs file to keep it all in one place?

[sampsyo]

All sounds good, and the implementation looks great! As we discussed synchronously, this "fixup" behavior for backing out some cross-component inference seems like the right thing.

The one thing I realized I don't completely understand about this is: I think the rule is (using your scenario above) we need to remove inferred latencies from B if B writes to A. I don't quite understand why writes are important in particular… I guess I would have expected the documentation for the function to say, like, "uses" or something. Is it just because any use involves a write to some input port (at least to the go port)? And merely reading from ports does not actually activate the control of the component?

[calebmkim]

I don't quite understand why writes are important in particular… I guess I would have expected the documentation for the function to say, like, "uses" or something. Is it just because any use involves a write to some input port (at least to the go port)? And merely reading from ports does not actually activate the control of the component?

Yeah; in fact, I think my implementation was a bit imprecise (i.e., it removes the @promotable attribute too easily). A more precise rule could be something like: we need to remove inferred latencies from B if B writes to the go port of A. Just reading from A shouldn't affect the component's latency.

[sampsyo]

Makes sense; thanks for clarifying! This level of precision seems fine to leave to future work. 😃

[rachitnigam]

Does this fix #1852?

[calebmkim]

No, but I have a PR that's almost ready that will fix it.

[calebmkim]

I'll merge this (I have more PRs coming, so I can adress any changes in those PRs as well).