4 ms·
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
by 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 agoI'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 agoCould 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 agoFrom 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 agoThat 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.