LLVM has very high quality standards in my experience. Much higher than I've ever had even at work. It might be a challenge to get this upstreamed.
LLVM is also very modular which makes it easy to maintain forks for a specific backend that don't touch core functionality.
Do you know why it's a fork? Als, from this https://github.com/ROCm/llvm-project/commits/amd-staging/ it looks like it might be more appropriately called a staging branch than a fork.
Various reasons, like embargoes on information, stuff we didn't want to wait for review on before shipping, or features that don't make sense for upstream like `hipcc` which is an `nvcc` wrapper.
Our goal is to get most modifications not in the third category into upstream at some point which makes the maintenance load bearable.
Super interesting, thanks. I specifically thought that its modular aspect made it possible to just "load" architectures or parsers as ... "plugins"
But I'm sure it's more complicated than that. :-)
Thanks again
LLVM backends are indeed modular, and the LLVM project does allow for experimental backends. Some of the custom optimization passes introduced by this MOS backend are also of broader interest for the project, especially the automated static allocation for provably non-reentrant functions, which might turn out to be highly applicable to GPU-targeting backends.
It would be interesting to also have a viable backend for the Z80 architecture, which also seems to have a highly interested community of potential maintainers.
https://github.com/jacobly0/llvm-project
... but now three years out of date, because it's hard to maintain :-)
My experience is that while LLVM is very modular, it also has a pretty high amount of change in the boundaries, both in where they're drawn and in the interfaces between them. Maintaining a fork of LLVM with a new back-end is very hard.