sampsyo
commented
2 years ago Thanks for getting this started! I think you need to make this proposal a bit more concrete/specific before it's ready to go. I understand that you want to build some kind of hardware-generating dialect in MLIR, but I don't yet understand what that dialect will look like. Here are some important questions to answer (although I'm sure this isn't everything and you can come up with other questions to answer too):
- What is the source language (what language or other MLIR dialect will this compile from)?
- What is the target language (what language or other MLIR dialect will this compile to)? You mentioned Bluespec, but I don't quite see why you've chosen it—elaborating on your design could help explain that. Since you're going into the MLIR ecosystem, the default choice would be to generate an existing MLIR dialect, such as
hworfirrtlorsv. - What are the main constructs that will exist in your new dialect? How will they differ from existing dialects in the CIRCT umbrella, such as
handshakeorfsmorstaticlogic? - What will be the main strategy used in your compiler? That is, what are the main compilation problems that your implementation will need to solve?
Also, 6120 projects need to have a significant evaluation component. To make this a viable proposal, you will need a larger empirical evaluation than compiling "hello world." Can you make a plan that empirically measures the effectiveness of your new compiler using some kind of quantitative metric and some realistic use cases?
yy665
Background MLIR is a modular, hybrid IR that is built based upon LLVM and could support a very diverse set of requirements, including dataflow graphs for Machine Learning, Polyhedral Optimizations, and hardware synthesis tools/HLS.
One of the super exciting tools that extends MLIR is called CIRCT. CIRCT is an innovative approach on hardware tooling that tries to apply LLVM methodology.
What will you do? This sounds like a big project with uncontainable scope. To actually make it happen with one manpower (myself) and one month, I am planning on just building a limited prototype that could describe a very basic data-path that could do some simple computation and memory operations. A more important target would be figuring out some major design choices for this compiler/dialect (to make this idea more concrete), including the set of hardware we’d like to support, abstractions for hardware module and transformation, guarantees/invariants we are offering, and extension points.
Unlike CIRCT which targets RTL level, I would like to aim for a higher abstraction to make the reasoning/transformation easier, but not at the HLS level to retain expressiveness.
How will you do it? I still need sometime to dig into MLIR and CIRCT to figure this out, but what I could tell at this point is that I definitely need to extend the MLIR to include some hardware primitives. I will also be likely to have BLUESPEC as my target language and write the codegen.
How will you empirically measure success? A “Hello World” hardware (in BLUESPEC) generated by the compiler that has the correct semantics.
A design document that has answered all major questions, with graphs to depict the structure/components of the language and the compiler. (To lay the ground for any future work)
Team members: For now just me.