fabianschuiki / moore

A hardware compiler based on LLHD and CIRCT
http://www.llhd.io
Apache License 2.0
243 stars 31 forks source link

Link against CIRCT and use it for codegen #234

Closed fabianschuiki closed 2 years ago

fabianschuiki commented 2 years ago

This PR makes Moore link against the circt library and uses that to generate code.

More specifically, this adds a circt-sys crate with the low-level bindings against the MLIR C library (generated by the bindgen crate), and a circt crate which contains some higher-level wrapper code that makes CIRCT and MLIR easier to use from Rust code. Note that we do not establish any kind of safety in Rust terms, but the API is "safe enough" for what we're trying to use it for.

Currently codegen.rs calls the original LLHD crate and the new CIRCT bindings in parallel to generate code. This was useful as a sanity check and to make sure the CIRCT-based emission is up to par with the LLHD crate. At a later point we should strip codegen down to use only CIRCT.

This PR also adds a --format=mlir-native output option which uses MLIR's dialect printer to emit the assembly.

fabianschuiki commented 2 years ago

@maerhart I'd love to get your feedback/review on this, since you also opened issue #232 :smiley:

fabianschuiki commented 2 years ago

Thanks a lot for the extremely detailed review @maerhart! This is awesome, and you caught quite a few bugs :grimacing:.

Additionally, it could be useful to add some instructions to the README on how to build moore as it got quite a bit more complicated with CIRCT as a submodule (or did I miss some automation?).

Yeah that is a good idea. I'll add the snippet to the README. I was considering making the circt-sys crate fetch and build LLVM and CIRCT automatically if you don't provide the environment variables, but not sure if a 2 hour cargo check is what the user would expect. Maybe it's easier to just provide good instructions to the user, as you suggest?

maerhart commented 2 years ago

Maybe it's easier to just provide good instructions to the user, as you suggest?

I'd say good instructions are good enough for now. Automatic fetch and build is certainly more convenient from a user perspective (provided it always succeeds), but it should definitely print in the CLI when it does so and report the progress, otherwise one might think it ran into an infinite loop or so 😆