
Llvm-Cbe: Resurrected LLVM “Bitcode to C Back End” with Improvements - vmorgulis
https://github.com/JuliaComputing/llvm-cbe
======
KenoFischer
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...](http://juliacomputing.com/blog/2016/03/10/j2c-announcement.html)

~~~
dannyobrien
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...](http://lists.llvm.org/pipermail/llvm-
dev/2010-February/029659.html)

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

------
digikata
I wonder if this works Rust-to-C?

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

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

~~~
ckok
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!

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

