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
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).
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
+1 in general, it had come up a few times and I was talking about this just last week (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? (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).
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: https://github.com/ScottTodd/iree-llvm-sandbox/tree/web-tools/web-tools). 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
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.
(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)