[Calyx] Separate SCFToCalyx and StaticLogicToCalyx.

[cgyurgyik]

Currently, these two conversions are in the same file. However, we should place them in separate files and share any duplicated code.

[mikeurbach]

Thanks for opening this. I've had this in mind for a bit, so here are my thoughts:

The SCFToCalyx pass could have most of the core implementation shared between SCF and StaticLogic. There is already a WhileOpInterface that (mostly) abstracts the differences. IMO the goal is to get this refactored so there is lib/Conversion/SCFToCalyx which just has a SCFToCalyx::runOnOperation, and lib/Conversion/StaticLogicToCalyx which just has StaticLogicToCalyx::runOnOperation. All the guts of the pass can live somewhere shared, like lib/Dialect/Calyx/Transforms/LoweringUtils.

To work towards that, I was planning on a few steps:

1. Factor everything other than the existing SCFToCalyx::runOnOperation into some shared place, including the LoweringState, ComponentLoweringState, and all the patterns
2. Create a separate StaticLogicToCalyx pass that is mostly a copy of what is left of SCFToCalyx
3. Rearrange any shared bits that are only required for one pass or the other so they are not shared and only included where needed. For example, there are some parts of ComponentLoweringState specific to StaticLogic, and we could make a ComponentLoweringState subclass which adds those fields, only for StaticLogicToCalx. As another example, there are patterns that only exist for StaticLogic, and most of the SCF patterns aren't needed for StaticLogic, so the StaticLogicToCalyx::runOnOperation can be trimmed down.

[cgyurgyik]

The SCFToCalyx pass could have most of the core implementation shared between SCF and StaticLogic.

All the guts of the pass can live somewhere shared, like lib/Dialect/Calyx/Transforms/LoweringUtils.

The first statement threw me off, StaticLogic pass shouldn't depend on the SCF pass. Perhaps I'm misunderstanding though, because I agree that the second statement is the way to go. I imagine a lot of frontends to Calyx will benefit from shared lowering utils, especially when it comes to distinguishing combinational/non-combinational groups.

[mikeurbach]

Sorry, I just meant "The SCFToCalyx pass as it exists today could have most of the core implementation shared between SCF and StaticLogic tomorrow

[cgyurgyik]

It's becoming difficult to debug the code at this point, so I'll see if I can tackle this.