Llvm-Cbe: Resurrected LLVM “Bitcode to C Back End” with Improvements

From that email it sounds like there was more concern about the front-end side C/C++->LLVM-IR than the backend side, so this wouldn't affect that. As for the backend side of things, I know nothing about Plan 9, so I can't comment if their dialect would require modifications to this could base. However, I can't imagine that making the changes to support Plan 9 natively in LLVM would be significantly more onerous than changes required to this backend. In fact, a lot of the ABI work may have been done already since I believe Go shares the Plan 9 ABI.

That seems like a lot of extra work. The end goal is to have clang on plan9? Create a plan9 target and then use clang to cross compile itself for plan9.

| I've heard that this focuses heavily on what Julia needs, and so the less exercised portions may need a bit of work.

Quite possibly yeah. Jameson had to do quite a bit of work to get the backend to a point where it would reliably work on the IR we generate. Now, julia does have a pretty wide coverage of LLVM IR, so it's probably not terrible, but as always the test cases used in development determine what works and everything else probably requires some work (actually very similar to the regular LLVM backends - whenever we port to a new architecture we first end up having to fix about a dozen bugs to do previously unexercised code paths).

| Is there a wider interest in resurrecting this for wider use?

We don't currently have an active use case. Jameson has been maintaining it on low flame and merging pull requests/doing some cleanup here and there, but since we're not actively using it, there is of course a limit to that. There has been some activity on the repository recently though, so you're not the only one interested.

Anything in regard to using less locals and more nesting, like previously:

a(b(c)) became int val = b(c) a(val)

even though val never was used anymore after this

Either way pretty cool!