Llvmcpy – Python bindings for LLVM auto-generated from the LLVM-C API(rev.ng)
rev.ng
Llvmcpy – Python bindings for LLVM auto-generated from the LLVM-C API
https://rev.ng/llvmcpy
16 comments
Please forgive my ignorance, but how would this be useful? I am not familiar with compilers or what having bindings in Python to a compiler would help.
You could, for example, write a compiler in Python that generated native code (or LLVM bitcode to be passed to llc or whatever) via the LLVM API. Writing a compiler in Python vs. C/C++ would be a lot easier in a number of ways.
I'm not aware of any "production grade" compilers that do this, but no hard reason why not, I guess. Seems like it'd be nice for prototyping etc. if nothing else.
I'm not aware of any "production grade" compilers that do this, but no hard reason why not, I guess. Seems like it'd be nice for prototyping etc. if nothing else.
Check out numba. It does this for a subset of Python.
More on what Thomas said:
http://www.llvmpy.org/
http://www.llvmpy.org/
"This project has been deprecated and is no longer being actively developed. We strongly suggest migrating to llvmlite.
"
try http://llvmlite.pydata.org/en/latest/ explanation why http://llvmlite.pydata.org/en/latest/intro/index.html
try http://llvmlite.pydata.org/en/latest/ explanation why http://llvmlite.pydata.org/en/latest/intro/index.html
So could I use this to conveniently optimize frequently called or inner loop functions?
Want to make an obscure (your own?) language faster or extend it for your usecase? Write a frontend in python and let llvm do the hard parts.
Two big use cases are building your own compiler in Python and doing some JIT compilation (E.g. regex matcher or similar) to gain some perf.
LLVM is fantastic but not everyone wants or can use C++ in their project.
I've been doing prototype compilers in Haskell, but Python might also be a nice choice.
LLVM is fantastic but not everyone wants or can use C++ in their project.
I've been doing prototype compilers in Haskell, but Python might also be a nice choice.
Didn't see in the readme: why "final"? I could see it being considered complete or failed, but it's unclear.
I believe it's because llvmlite is now suggested.
The llvmpy page mentions:
> Warning
> This project has been deprecated and is no longer being actively developed. We strongly suggest migrating to llvmlite.
http://llvmlite.pydata.org/en/latest/
The llvmpy page mentions:
> Warning
> This project has been deprecated and is no longer being actively developed. We strongly suggest migrating to llvmlite.
http://llvmlite.pydata.org/en/latest/
Why is this relevant? Are llvmpy and llvmcpy related?
Oh, my bad. You're right, I got my links mixed up.
aleclm has responded with the correct answer, ignore mine.
aleclm has responded with the correct answer, ignore mine.
Final in the sense that hopefully we won't need a fourth one. It should provide the best performance (since the IR is not re-encoded in Python) and I've tried to make it flexible and future proof. llvmlite currently only supports LLVM 3.8, while I quickly tested llvmcpy with 3.4, 3.8 and 3.9 and works flawlessly.
Still quite alpha, though.
Still quite alpha, though.
How does this compare to llvmlite?
Is this going to support a larger portion of the LLVM API?
Is this going to support a larger portion of the LLVM API?
It looks to be a less complete solution, since it only relies on the LLVM C API which is incomplete. llvmlite digs into the C++ API as well, so while it has more work to do to keep up with changes in LLVM, it's more more feature-complete
The LLVM-C API is quite powerful, and I'm planning to upstream some patch to expose additional stuff.
On the other hand, llvmlite doesn't even parse existing IR, it's basically write-only. Plus, representing the IR in Python makes it less memory efficient than using the native representation.