[RFC] Stream Dialect

Incubator CIRCT
#21

How do we continue from here?
Assuming that there is a general interest in having a streaming abstraction, there are three ways of continuing this work.

Option 1: Continue as a standalone project

Instead of integrating the dialect in one of the existing projects, the development can continue as a standalone project that depends on MLIR and CIRCT. This approach gives the project high flexibility as we can design the dialect without the concerns of other parts of the community. On the other hand, this might end up in a product that doesn’t align with the community’s goals and will potentially end up unused.

Option 2: Adding the dialect to CIRCT

One option to interact with the community is to add the dialect to CIRCT. Currently, the only lowering implemented targets the handshake dialect, a dynamic HLS dialect. By bringing other HLS-focused dialects and lowerings into CIRCT, the project might motivate more research groups to contribute their work to this ecosystem. I understand that this might be a stretch of CIRCT’s goals and could cause an unwanted dialect explosion.

The problem I do see here is the fact that lowerings to other targets, e.g., CPUs and GPUs, are not something related to CIRCT. Providing a “general” streaming abstraction that can only target hardware seems an unnecessary limitation. One could also try to push the dialect forward in CIRCT and later “graduate” it by moving it into MLIR.

Option 3: Adding the dialect to MLIR

Ideally, such a dialect would directly land in MLIR as it allows all kinds of users to target it while also enabling a variety of backends. In this case, the stream-to-handshake transformation could be a part of CIRCT while the input dialect is not, similar to std-to-handshake.

At this point, I do not have plans to implement lowering from the stream dialect to CPU or GPU abstractions. Although I would be interested to work on these, the thesis project is my current priority. I fear that without someone that plans to implement these lowerings, the MLIR community will not accept such a contribution. I can create an RFC for the MLIR community, but I would first like your feedback on this.
Note: I talked to @shraiysh, and he would be interested in playing around with this, but he cannot commit to such a large task. Feel free to correct me Shraiysh :slightly_smiling_face:

Any thought on this?

2 Likes
#22

Given that it’s more likely for adoption into the main code base after there’s a working prototype for a specific use case, I think option 2 is the most promising way to get the stream technique included in the LLVM/MLIR code base.

3 Likes