4 ms·

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

48 points by vmorgulis 10y ago

KenoFischer 10y ago
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.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...
- jjnoakes 10y ago
  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.
  - KenoFischer 10y ago
    | 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.
- dannyobrien 10y ago
  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/029659.html http://lists.llvm.org/pipermail/llvm-dev/2010-February/02965...
  - KenoFischer 10y ago
    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.
  - ksherlock 10y ago
    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.
ckok 10y ago
Where can i Find what the improvements actually are over the original?
- KenoFischer 10y ago
  The improvements are better coverage of possible LLVM IR, and significant bug fixes to make this actually work.
  - ckok 10y ago
    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 10y ago
      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.
digikata 10y ago
I wonder if this works Rust-to-C?

48 points by vmorgulis 10y ago

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.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...

jjnoakes 10y ago
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.
- KenoFischer 10y ago
  | 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.
dannyobrien 10y ago
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/029659.html http://lists.llvm.org/pipermail/llvm-dev/2010-February/02965...
- KenoFischer 10y ago
  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.
- ksherlock 10y ago
  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.

ckok 10y ago

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

KenoFischer 10y ago
The improvements are better coverage of possible LLVM IR, and significant bug fixes to make this actually work.
- ckok 10y ago
  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 10y ago
    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.

digikata 10y ago

I wonder if this works Rust-to-C?