SUMMARY:
Unladen Swallow should be able to load arbitrary modules/packages compiled to
LLVM bitcode in addition to its current support for loading either compiled
native code or Python source code.
IN-DEPTH EXPLANATION:
Unladen Swallow is currently capable of loading code in two forms: native code
or Python code. (For this issue, I'll treat Python byte code and source code as
equivalent.) This prevents the benefits C/C++ extensions from benefiting from
LLVM JIT optimisations.
Of particular interest, loading bitcode should yield performance improvements
modules containing functions which are good candidates for inlining. For
example, the ‘llvm_inline_functions’ source file[1] is currently
compiled[2] in a somewhat hackish manor; it's compiled to bitcode first and the
bitcode is then
‘compiled’ to C++ code, for compiling and linking into the main Python
executable/library. This is a somewhat fragile approach and not really reusable
either.
The primary disadvantage, however, to loading bitcode is that it could cause
significant delays to load times.
Instead, I would propose an alternate, possibly optional, mode for compiling C
extension modules: compile the module into both a loadable library and an
LLVM bitcode object. At load, the Python VM would then initially load the
native library to speed up start-up time, but also for calls from the
interpreter into
the extension. Should code calling into the extension then be deemed ‘hot’,
the bitcode object would be loaded and linked into the to-be-compiled code, but
with internal linkage. LLVM inliners would then determine whether the code was
suitable for inlining, and if not, calls would resolve to the existing native
code.
Prior to compiling the LLVM IR, the distinct loaded functions would be deleted
— by regular DCE or a custom pass — preventing redundant compilation.
Please note that this strategy could apply to extension modules written in both
C and C++; although the Clang support for C++ is incomplete, LLVM-GCC is
quite mature in this regard. Actually, it's also more portable than Clang is
currently.
[1]
<http://code.google.com/p/unladen-swallow/source/browse/trunk/Python/llvm_inline
_functions.c>
[2]
<http://code.google.com/p/unladen-swallow/source/browse/trunk/Makefile.pre.in#74
6>
COMPLEXITY:
Getting this right is arguably non-trivial, and will require touching both the
core VM and distutils. The devil lies in the detail; I might be able to help
with the
latter, but I'm afraid the former is out of my league.
Original issue reported on code.google.com by danchr on 13 Sep 2009 at 11:47
Original issue reported on code.google.com by
danchron 13 Sep 2009 at 11:47