[llvm-dev] Proposal for CIRCT incubator project

[Stephen Neuendorffer via llvm-dev]

For the past several months, members of the ‘CIRCT’ group have been working to begin adapting MLIR for hardware design.  We believe that this area would benefit from good open source infrastructure enabling research and, eventually, the next generation of commercial tools.  We have collected several dialects and envision a number of lowering flows using these dialects.  We have reached the point where we are ready to share our ideas more widely and would like to be considered as an LLVM incubator project.

Our code exists at https://github.com/circt as an out-of-tree MLIR project and our group charter can be found at https://github.com/circt/circt/blob/master/README.md.   We have weekly discussions with a group of about 20 people from Xilinx, SiFive, Microsoft, PNNL, ETH Zurich, EPFL, Stanford, and Cornell, and welcome additional contributions.  This project is still early and we see many elements as highly experimental.  At the same time, we feel that the only way to vet these ideas is to build larger systems which will likely take some time and community investment. The LLVM incubator process would be a good way to help us organize this effort.

Steve Neuendorffer

Xilinx Research Labs   

[Hal Finkel via llvm-dev]

Hi, Steve,

I think it would be great to have hardware-synthesis capabilities in the LLVM project. The incubation process discussion may be ongoing, but as that settles, this seems like a good candidate to me.

Out of curiosity, many existing HLS tools use C/C++-derived input languages, and as Clang produces LLVM, do you have any plans for a converter between LLVM and your MLIR dialects? Or are you just targeting other kinds of frontends?

Thanks again,

Hal

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

[Stephen Neuendorffer via llvm-dev]

Thanks Hal,

The front-end question is still a tricky one.  Having a low level CDFG in MLIR doesnt really offer much and I see rebuilding the clang code generator to emit loops directly in MLIR as a complex piece of work.  I think the most natural place to interact with Vivado HLS is towards the backend at the moment where MLIR could give more points of interaction late in the HLS flow.  Eventually the community will sort out the front-end questions do tackling that hasn't been high on my list.  Simply rebuilding HLS flows is also not necessarily the goal here, although it's a natural place to start.  From a Xilinx perspective we also have heterogeneous devices with lots of vector VLIW cores.  Integrating them into an HLS-like flow is also very interesting.

Steve

[Chris Lattner via llvm-dev]

Hi Hal,

The project is still early and we’ve been working on building out some core infrastructure.  There are lots of things (including existing synthesis frontends) that could benefit from this work.  I’d love to see folks interested in clang integration join the group!

-Chris

[Chris Lattner via llvm-dev]

Thanks Steve!  The incubator process just landed, it would be great to outline how CIRCT aligns with the new guidelines set out in that document.  As you know, I’m personally very much in favor of this project landing, but am also have a conflict of interest, so I’d like to know what other community members think.

-Chris

[Mehdi AMINI via llvm-dev]

Hey Stephen,

I'm very positive on this project joining the incubator. I think extending the LLVM project support for applying compiler infrastructure and techniques to hardware design is very interesting!

This is also a fantastic application for MLIR, and it will (and already did) influence the development of the framework.

Looking forward to this!

-- 

Mehdi

[Stella Laurenzo via llvm-dev]

I'm really looking forward to this/supportive.

[Stephen Neuendorffer via llvm-dev]

Sure, I'll summarize with respect to the criterion in the document:

• Must be generally aligned with the mission of the LLVM project to advance compilers, languages, tools, runtimes, etc.

CIRCT is a compiler which is built around LLVM/MLIR.  We anticipate building code generation for ASIC and FPGA backends along with specialized accelerators, while leveraging existing LLVM backends for processor targets.

• Must conform to the license, patent, and code of conduct policies laid out in this developer policy document.

Contributions are currently ApacheV2 licensed and we have adopted the general structure of the LLVM developer policies already, to the extent that we can as an external project.

• Must have a documented charter and development plan, e.g. in the form of a README file, mission statement, and/or manifesto.

See  https://github.com/circt/circt and https://github.com/circt/circt/blob/master/docs/Charter.md 

• Should conform to coding standards, incremental development process, and other expectations.

The project mostly consists of MLIR dialects and transformations following the MLIR standalone dialect example implemented using c++14 and FileCheck for regressions.  We are currently using Github PRs for code review and a nifty CI system that caches the most recent LLVM build for good performance using github hosted builds.  See  https://github.com/circt/circt   

• Should have a sense of the community that it hopes to eventually foster, and there should be interest from members with different affiliations / organizations.

We have weekly meetings with >20 people from Xilinx, Sifive, Microsoft, PNNL, ETH, EPFL, Cornell, and Stanford.  Meeting minutes are here:https://docs.google.com/document/d/1fOSRdyZR2w75D87yU2Ma9h2-_lEPL4NxvhJGJd-s5pk/edit#  

• Should have a feasible path to eventually graduate as a dedicated top-level or sub-project within the LLVM monorepo.

I think this is very feasible from the perspective of code structure, but I would want to get to the point where we have stable APIs and useful end-to-end toolflows before advocating for that.

• Should include a notice (e.g. in the project README or web page) that the project is in ‘incubation status’ and is not included in LLVM releases (see suggested wording below).

We can easily add this if accepted by the community.

• Must be proposed through the LLVM RFC process, and have its addition approved by the LLVM community - this ultimately mediates the resolution of the “should” concerns above.

'[RFC]' indicated in the subject line.  I assume that this doesn't yet qualify as a contentious decision. :)

Steve

[Eric Christopher via llvm-dev]

This seems pretty cool and as a "not involved with any of the projects being used outside of llvm" observer I support the inclusion of this project in the incubator. :)

-eric

[Renato Golin via llvm-dev]

It would be nice to have an external MLIR user in the project, and
this project seems really well organised and relevant. +1 from me,
too.

[Chris Lattner via llvm-dev]

> On Jul 8, 2020, at 8:52 AM, Renato Golin via llvm-dev <llvm...@lists.llvm.org> wrote:
>
> It would be nice to have an external MLIR user in the project, and
> this project seems really well organised and relevant. +1 from me,
> too.

I think that flang beat us to the punch as the first external MLIR user :-) but thank you for your support Renato!

-Chris

[Renato Golin via llvm-dev]

On Wed, 8 Jul 2020 at 22:43, Chris Lattner <clat...@nondot.org> wrote:
> I think that flang beat us to the punch as the first external MLIR user :-) but thank you for your support Renato!

Ah, but Flang is in the monorepo and builds together with LLVM, while
CIRCT (and my current project, Verona) "uses" MLIR/LLVM externally (as
a submodule).

There are a number of build issues in both LLVM and MLIR that make it
awkward for projects in that category to use the LLVM libraries and
having a project in the llvm group will give us an "official" reason
to solve those problems more efficiently.

I've been meaning to start a thread on that, but I need to collect all
the build issues I had in an email so we can discuss them. Not for
this thread, though. :)

cheers,
--renato

[Stephen Neuendorffer via llvm-dev]

Renato, I'm happy to kibitz on the build problems.  Cmake seems to be working well at this point for us, but it took quite a bit to get there and there are some pitfalls. I'm aware of some namespace issues in mlir, but haven't gotten around to dealing with them.  

Steve

[Stephen Neuendorffer via llvm-dev]

Renato,

After looking at your testcase, it seems that you're trying to relocate a 'build' directory and are having to rewrite absolute paths in the build directory.

Build directories are not really relocatable, partly because of absolute paths, and partly because of dealing with shared library rpaths IIRC.  I tried your testcase

with an install directory and it seems to work (at least for the MLIR parts) even if the install directory is relocated. This is because a different set of cmake exports

are generated for install directories.  Also note also that MLIR does install the .inc files generated by tablegen for this to work.

Steve

[Renato Golin via llvm-dev]

Hi Steve, 

Thanks for the update! This will fix the ugliest hack I have on my build script.

I know I wasn't doing the nicest thing, but it's nice to see that what I needed wasn't that far away. 

I'll update my scripts and get back to you. 

Really appreciate, thanks! 

Renato 

[Aaron Smith via llvm-dev]

Onnx-mlir is another example of an upstream MLIR project linking against the LLVM build directory.

https://github.com/onnx/onnx-mlir

_______________________________________________

[Renato Golin via llvm-dev]

On Fri, 10 Jul 2020 at 17:02, Aaron Smith <aaron.l...@gmail.com> wrote:
> Onnx-mlir is another example of an upstream MLIR project linking against the LLVM build directory.
> https://github.com/onnx/onnx-mlir

Nice! This is more advanced than I imagined! :)

[Chris Lattner via llvm-dev]

Great, thanks Eric and others.  It sounds like there is general support with no concerns, let’s do it.  Thanks!

-Chris