[StaticLogic] Back PipelineWhileOp with a Scheduling problem.

Nobody has claimed this yet.

In https://github.com/llvm/circt/pull/2183 we started trying to add verification of the PipelineWhileOp's II. It quickly became clear that we didn't have the necessary information in the IR (for example, some attributes were proposed in https://github.com/llvm/circt/issues/2191). After some discussion, it seems that doing things like verifying the II of a pipeline is really the job of the scheduling infrastructure. We are working hard to do scheduling early in the HLS flow, so information like the II is already computed before we get to the point of creating this "high-level" pipeline operation.

For now, we are focusing on using PipelineWhileOp as a materialization of the scheduling problem's solution in the IR. An IR is only as useful as the transformations it allows, and at the moment, PipelineWhileOp is essentially immutable. The only transformations you can safely do are lowerings into something like Calyx, the FSM dialect, or something else. That is an important class of transformations, and we are content with this being a stepping stone between looping IRs and statically scheduled hardware IRs, but this restriction still leaves something to be desired.

In order to fully support interesting transformations that mutate a PipelineWhileOp, or infer properties like its II, @jopperm had a really interesting idea. I will try to summarize it here for further discussion. In short, we could back the operation with an instance of a scheduling problem. One could imagine a builder method that takes a CyclicProblem, SharedPipelineOperatorsProblem, ModuloProblem, etc. It might even be possible to teach to the parser to parse the PipelineWhileOp's syntax, construct a problem, and hand that to the builder.

This could open the door to some really interesting possibilities. The verifier would simply delegate to the scheduling problem. Want to infer the II? Ask the problem. In order to support transformation of the operation, we would expose APIs, like "move this operation to that stage". These would mutate the underlying problem, and the verifier would check that invariants like the II or resource limits are still valid.

I think this is a direction that is very interesting, and worth some exploration. For now, treating PipelineWhileOp as an IR that is the immutable result of scheduling seems like the safe thing to do until we have a need for such mutations.

Start by reading the PipelineWhileOp design described in this issue and compare it with the proposed CyclicProblem, SharedPipelineOperatorsProblem, and ModuloProblem abstractions. Explore how parsing, building, verification, II inference, and mutation APIs would interact. Done would require a concrete, agreed design or implementation plan; this issue does not identify files or tests.

Written by the indexing model from the issue text.