This has been passed around been a couple folks after it got ripped out of LLVM. Looks like we still have the most up-to-date version here. Happy to answer any questions if I can (if not I'll have to bug Jameson who did all of the work here ;)). See here for some context of what we used this for: http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...

Could this work bring closer the possibility of LLVM compiling itself into the Plan9 C dialect?

http://lists.llvm.org/pipermail/llvm-dev/2010-February/02965...

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.

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

There are a few other languages I would love to be able to use with this.

| 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.

I wonder if this works Rust-to-C?

Where can i Find what the improvements actually are over the original?

The improvements are better coverage of possible LLVM IR, and significant bug fixes to make this actually work.

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!

Don't think that particular optimization was ever implemented. It looks straightforward, but one does have to be careful about re-ordering, so the legality check is slightly more complicated. We briefly considered writing a clang-based source-to-source transformation as a post processing pass to clean up, but it wasn't worth it for our use case.