Establish a recipe for doing research built on HEIR

[j2kun]

As people are starting to do research on top of HEIR, we are hitting the problem where they want to keep their research efforts private, but still keep up to date with changes to HEIR as they work. We also want to make it easy to upstream such research efforts after the research is published.

GitHub does not allow one to make a private fork of a public repo, so I think what some have been doing is making a hard fork, which works except it doesn't make upstreaming or keeping up to date with HEIR changes easy.

One possibility is to make HEIR a dependency rather than a source fork. Then, e.g., one could create a new bazel WORKSPACE in a private repo that pulls in HEIR at a given commit, and the private repo would only contain source code for the new dialects/passes introduced. This would require us to add hooks to extend heir-opt and heir-translate so that new passes and pipelines could be registered alongside the upstream ones. Keeping up to date would require bumping the commit in the WORKSPACE, and upstreaming would not be as simple as opening a PR from a feature branch, but it might be simple enough. My main unknown here is how to provide those external registration hooks, but it might suffice to just add a layer of indirection like mlirOptMain for downstream users to call in their own binary wrapper.

With this setup we could provide a template repository that could be hard-forked and made private, and maybe even provide a script to convert appropriately-organized changes into upstream PRs.

[j2kun]

CC @WoutLegiest

CC @AlexanderViand-Intel do you have a process for work related to Intel?

CC @raghav198 who already did some research on HEIR; what pain points did you find?

[AlexanderViand-Intel]

CC @AlexanderViand-Intel do you have a process for work related to Intel?

Since the HERACLES SDK development is moving to "development in the open", there'll probably not be a need for an "internal" versions of HEIR for Intel in the future. In fact, the recent tests I've been doing already live in my public fork (cf. the p-ISA dialect draft, or my SDK-emitter branch). |

EDIT: Even with a public fork, though, there's frequently annoying merge conflicts in heir-opt.cpp (well, really Register<...>Pipelines.h/.cpp) and heir-translate.cpp (and the associated BUILD files) so it'd be great if we had a system to add dialects/passes/pipelines that was a bit less "monolithic".

EDIT2: In the long-term, we also probably don't want to force everyone to build HEIR with all possible backends/Vendor specific stuff, so even more reasons to make all of this is a bit more modular/decoupled.

[raghav198]

CC @raghav198 who already did some research on HEIR; what pain points did you find?

The main thing I could say here is maybe also related to better decoupling; there's some functionality that's currently implemented in backend-specific or pass-specific libraries that would maybe be better to factor out since it applies to multiple backends. (I think the main example I have in mind here was I ended up needing to either move or replicate a bunch of the OpenFhePkeEmitter stuff when I was writing the OpenFheBinEmitter, but I also vaguely recall needing to do something similar for a BGV pass)