Looking for ideas and requests regarding MLIR for Compiler Explorer (godbolt.org)

Hello friends,

I’m currently working on integrating MLIR/mlir-opt into Compiler Explorer/godbolt ([COMPILER REQUEST]: LLVM-MLIR · Issue #3730 · compiler-explorer/compiler-explorer · GitHub) and I figured it would be best to ask the MLIR developers and community about what functionality would be useful to have (or if Compiler Explorer support would be useful at all).

I’m currently able to do simple transforms, but I’d love to hear what you all think!

Any ideas, thoughts, and concerns are welcome :smiley:

Thanks! <3


Hey friend,
Thanks for doing this.
It would be awesome to figure out a way to make it work with user defined dialects as well. Kinda similar how the mlir/Tools/mlir-opt/MlirOptMain.h can be used to create your own version of mlir-opt

Thanks! Something else that would be nice would be to have MLIR available as a library for building C++ code samples:

Right, this is a bit tricky because CE simply runs the binary executable. It would, however, be possible to create new installers for custom MlirOptMain programs (I’ll be looking into some options + probably writing a guide for this).

1 Like

That’s a great idea, I’ll be looking into getting this set up!

Thanks for looking into this, I think this will be a handy utility. It will be great to support mlir-translate as well.

The Feature I’d personally like the most is line mapping from output back to the input via reading the location metadata. Similar to how LLVM IR can be read and mapped back to the input via it’s debug info (example: Compiler Explorer). This would ideally be implemented in a fashion so that not only mlir-opt but also future compilers that are based on MLIR (eg. flang) could also have their MLIR output conveniently mapped

The parser can already pick up locations using the input source, but have you looked into location snapshotting?

+1. Would really love to have this!

Great idea, I’ll also be looking into this. Thanks!

+1 in general, it had come up a few times and I was talking about this just last week :slight_smile: (well the library part that Mehdi mentioned as CE is so convenient to create link to inefficiencies or to double check what the generated code looks like)

It seems like you are able to give a full pipeline there, so this would allow stringing arbitrary passes together?

Is the question given what compiler explorer supports, what folks would like or how it would fit, or how would one want it extended? :slight_smile: (some previous suggestions at conferences, open design meetings etc had circled around stepping through transforms, but I don’t think those fit in CE’s feature set today … But I’m not an expert there).

Yeah, practically anything that can go into mlir-opt’s command line can be viewed in CE.

Stepping through transforms sounds like it’s pretty far out of CE’s feature set today so I’m not sure how possible that is going to be for now.

I built a little demo of this about a year ago, using IREE’s iree-opt (mlir-opt + some IREE passes): IREE-Fiddle Demo (source here: iree-llvm-sandbox/web-tools at web-tools · ScottTodd/iree-llvm-sandbox · GitHub). That has a box for input IR, flags for passes to run, output IR, and a slider for scrolling through the output after each pass. That also ran client-side after building the compiler for Wasm/JS via Emscripten.

I was also looking at Compiler Explorer / godbolt, as it offers some really nice features. I’d be excited to see the work you started progress :smiley:

Brainstorming things that Compiler Explorer could offer:

  • Output format / filtering could switch custom assembly formats on/off
  • Source location snapshots mapping output back to input (as mentioned by others)
  • Switch between different compiler versions (such as mlir-opt at different commits, and we also have some downstream forks of IREE’s compiler that could be useful to compare between)

This sort of tooling for MLIR is tricky though, because of how fragmented the uses of it can be, how unstable the textual format is, and how flexible MLIR is.

  • Allowing user-defined *-opt tools could help with fragmentation, but there’s probably a high barrier to entry there (vs just sharing a URL to what is already hosted)
  • Unstable IR (the func.func renaming as a recent example) might require regularly pushing new versions of the compiler (along with some versioning scheme), or risking previously saved sessions being broken
  • Different projects using MLIR (and different dialects within even the upstream/core project) use MLIR in different ways, so they might want different features out of the tooling. I don’t have concrete examples, but have a feeling that sticking to the common building blocks (viewing IR, running passes, etc.) will be important

I thinking having it working for dialects in LLVM repo & doc on how to run locally with your own dialects & passes linked in, would be a really nice delta.

And indeed stability will bite here a few times.


I’m happy to share that the MVP implementation is now publicly available (here is a lower-affine example Compiler Explorer)

Will be looking into adding MLIR as a lib (like @mehdi_amini suggested) + a write-up on how to add your own MlirOptMain programs locally next.

Thank you all for the feedback on this thread!


@supergrecko if you’d be able add Polygeist (GitHub - llvm/Polygeist) as a C/C++ frontend for generating MLIR as well that would be fantastic.

It would certainly help us with development towards feature completion, and also I hope be generally useful to others.

cc @ftynse

1 Like