I addition to cdavid's comment: LLVM IR is system independent. So if you had a deployment over heterogeneous machines you could write the extension code once and have it run everywhere without recompilation.

LLVM IR is not system independent.

http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-p...

Fair enough, that was too strong a claim. But it is more portable than an extension module compiled with the system compiler.

It's not portable enough to let me take IR generated for my x86 laptop and run it on my arm board, in general, even though both platforms are ILP32, little-endian, and running the same OS.

Yes, but this is a problem with the source language and/or the host system libraries, not with LLVM IR itself. There is a broad domain of applications for which it is portable.

I was confused about this too, but I think the idea is that it's easier to infer type information from the bitcode than from raw object code.

more closely related to ctypes than swig.

swig requires glue code (.i files) to be written and generated, then compiled. ctypes can take a system native library (.so or .dll) and access it.

bitey, on the other hand, uses platform-neutral llvm bytecode. imagine ctypes but platform neutral. that's bitey.

pretty darned cool.

once you can import llvm code at runtime, you are pretty close to injecting llvm code at runtime: you write some LLVM IR in a string, and "llvm_eval" it.