llvmpy / llvmpy Goto Github PK

Originally a github fork of the llvm-py repository from http://www.mdevan.org/llvm-py/index.html updated to work with LLVM 3.x. Since then it has changed significantly with multiple sub-projects.

Home Page: www.llvmpy.org

License: BSD 3-Clause "New" or "Revised" License

Shell 0.02% Python 42.50% Makefile 0.11% C 0.62% LLVM 2.09% C++ 3.42% JavaScript 0.24% HTML 50.26% CSS 0.74%

llvmpy's Introduction

llvmpy: Python bindings for LLVM

Important Note: Use llvmlite instead

This project is no longer maintained and users are recommended to switch to llvmlite, which is developed by llvmpy maintainers and numba developers. For temporary compatibility with llvmpy, llvmlite emulates the some API of llvmpy. This compatibility layer is enough to allow numba to transition to llvmlite with minimal code changes. Keep in mind that this compatibility layer is temporary. New code should be written for the llvmlite API, which is not very different.

Home page

http://www.llvmpy.org

Versions

This package has been tested with LLVM 3.3, Python 2.6, 2.7, 3.3 and 3.4. Other Python versions may work.

Quickstart

Get and extract LLVM 3.3 source tarball from llvm.org. Then, cd into the extracted directory.
Run ./configure --enable-optimized --prefix=LLVM_INSTALL_PATH.

Note: Without the --enable-optimized flag, debug build will be selected. Unless you are developing LLVM or llvmpy, it is recommended that the flag is used to reduce build time and binary size.

Note: Use prefix to select the installation path. It is recommended to separate your custom build from the default system package. Please replace LLVM_INSTALL_PATH with your own path.
Run REQUIRES_RTTI=1 make install to build and install.

Note: With LLVM 3.3, the default build configuration has C++ RTTI disabled. However, llvmpy requires RTTI.

Note: Use make -j2 install to enable concurrent build. Replace 2 with the actual number of processor you have.

Get llvm-py and install it:

$ git clone https://github.com/llvmpy/llvmpy.git
$ cd llvmpy
$ LLVM_CONFIG_PATH=LLVM_INSTALL_PATH/bin/llvm-config python setup.py install

Note: Some OS has a default python that may install to system locations thus requiring root permission. In that case, use:

$ LLVM_CONFIG_PATH=LLVM_INSTALL_PATH/bin/llvm-config python setup.py install --user

Run the tests:

$ python -c "import llvm; llvm.test()"

See documentation at 'http://www.llvmpy.org' and examples under 'test'.

Ubuntu 14.04 installation instructions

To install llvmpy with pip on ubuntu 14.04, follow these steps:

Make sure both the system version of llvm and version 3.3 is installed:
```
$ sudo apt-get install llvm llvm-3.3
```
Install the non-released package of llvmpy that has support for multiple versions of llvm (as described in #126):
```
$ pip install https://pypi.python.org/packages/source/l/llvmpy/llvmpy-0.12.7-9-g60b512d.tar.gz
```

Common Build Problems

If llvmpy cannot be imported due to "undefined symbol: _ZTIN4llvm24PassRegistrationListenerE", it is because RTTI is not enabled when building LLVM. "_ZTIN4llvm24PassRegistrationListenerE" is the typeinfo of PassRegistrationListener class.
LLVM3.3 ssize_t mismatch on 64-bit Windows. Get patch from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130701/180049.html
OSX 10.9 Mavericks uses libc++ by default but Anaconda distributes LLVM binaries link with the old libstdc++. The two binaries are incompatible but there are no compile/link time warnings. The resulting binaries may generate segmentation fault at runtime (probably due to ABI mismatch). The Fix: Use the following c++ flags: -std=libstdc++ -mmacosx-version-min=10.6.
OSX 10.10 user will need to change the Makefile of LLVM 3.3 due to a version match error. At line 574 of llvm3.3 Makefile.rules, modify DARWIN_VERSION := $(shell echo $(DARWIN_VERSION)| sed -E 's/(10.[0-9]).*/\1/') to DARWIN_VERSION := $(shell echo $(DARWIN_VERSION)| sed -E 's/(10.[0-9]+).*/\1/') (Note the extra "+" in the regex). See #130 for the original issue.

LICENSE

llvmpy is distributed under the new BSD license, which is similar to the LLVM license itself. See the file called LICENSE for the full license text.

llvmpy's People

Contributors

Stargazers

Watchers

llvmpy's Issues

Failed Install: error: ‘LLVMInitializeNVPTX*' was not declared in this scope

I am eager to try llvm 3.2 with python and so have just recompiled my llvm3.2 with --enable-pic and then cloned this github repo, oh side note i coulnt do git clone [email protected]:llvmpy/llvmpy.git because of permissions or something so i had to use git clone https://github.com/lvmpy/llvmpy.git, and then i ran the following line to install llvmpy with my python 3.2 setup on ubuntu.

[~/src/llvmpy]> sudo python3 setup.py install LLVM version = 3.2 Generate intrinsic IDs No CUDA support running install running build running build_py copying llvm/_intrinsic_ids.py -> build/lib.linux-i686-3.2/llvm running build_ext building 'llvm._core' extension gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/usr/include -I/usr/local/include -I/usr/include/python3.2mu -c llvm/_core.cpp -o build/temp.linux-i686-3.2/llvm/_core.o cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] llvm/_core.cpp: In function ‘PyObject* _wLLVMInitializeNVPTXTarget(PyObject*, PyObject*)’: llvm/_core.cpp:1045:1: error: ‘LLVMInitializeNVPTXTarget’ was not declared in this scope llvm/_core.cpp: In function ‘PyObject* _wLLVMInitializeNVPTXTargetInfo(PyObject*, PyObject*)’: llvm/_core.cpp:1046:1: error: ‘LLVMInitializeNVPTXTargetInfo’ was not declared in this scope llvm/_core.cpp: In function ‘PyObject* _wLLVMInitializeNVPTXTargetMC(PyObject*, PyObject*)’: llvm/_core.cpp:1047:1: error: ‘LLVMInitializeNVPTXTargetMC’ was not declared in this scope llvm/_core.cpp: In function ‘PyObject* _wLLVMInitializeNVPTXAsmPrinter(PyObject*, PyObject*)’: llvm/_core.cpp:1048:1: error: ‘LLVMInitializeNVPTXAsmPrinter’ was not declared in this scope error: command 'gcc' failed with exit status 1

As you can see there are a few errors here about missing declarations it is having problems with. Did i do something wrong here? I have seen Eli Bendersky's page on llvmpy here http://eli.thegreenplace.net/2012/08/10/building-and-using-llvmpy-a-basic-example/ and it says to compile llvm with --enable-shared=yes --enable-pic --disable-libffi and i included only --enable-optimized --enable-pic is that my problem?

I chose not to use those options as they where not specified in the current readme on installation and Eli's version of llvmpy is a bit older.

Implement PyModuleDef and related to simplify generating PY3 modules

The structure is described here

http://docs.python.org/3.1/c-api/module.html#PyModuleDef

Compiler errors against LLVM 3.4

Using LLVM 3.4, Python 3.3.3, GCC 4.8...

llvmpy/api.cpp: In function ‘PyObject* llvm_GlobalValue__LinkageTypes__LinkOnceODRAutoHideLinkage(PyObject*, PyObject*)’:
llvmpy/api.cpp:13957:46: error: ‘LinkOnceODRAutoHideLinkage’ is not a member of ‘llvm::GlobalValue’
     PyObject* var_PyObject4 = PyInt_FromLong(llvm::GlobalValue::LinkOnceODRAutoHideLinkage);
                                              ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasAsmPrinter(PyObject*, PyObject*)’:
llvmpy/api.cpp:20343:38: error: ‘class llvm::Target’ has no member named ‘hasAsmPrinter’
     bool var_bool = var_llvm_Target->hasAsmPrinter();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasMCCodeEmitter(PyObject*, PyObject*)’:
llvmpy/api.cpp:20373:38: error: ‘class llvm::Target’ has no member named ‘hasMCCodeEmitter’
     bool var_bool = var_llvm_Target->hasMCCodeEmitter();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasMCDisassembler(PyObject*, PyObject*)’:
llvmpy/api.cpp:20488:38: error: ‘class llvm::Target’ has no member named ‘hasMCDisassembler’
     bool var_bool = var_llvm_Target->hasMCDisassembler();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasAsmStreamer(PyObject*, PyObject*)’:
llvmpy/api.cpp:20518:38: error: ‘class llvm::Target’ has no member named ‘hasAsmStreamer’
     bool var_bool = var_llvm_Target->hasAsmStreamer();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasMCAsmParser(PyObject*, PyObject*)’:
llvmpy/api.cpp:20619:38: error: ‘class llvm::Target’ has no member named ‘hasMCAsmParser’
     bool var_bool = var_llvm_Target->hasMCAsmParser();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasMCInstPrinter(PyObject*, PyObject*)’:
llvmpy/api.cpp:20649:38: error: ‘class llvm::Target’ has no member named ‘hasMCInstPrinter’
     bool var_bool = var_llvm_Target->hasMCInstPrinter();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_Target__hasMCObjectStreamer(PyObject*, PyObject*)’:
llvmpy/api.cpp:20981:38: error: ‘class llvm::Target’ has no member named ‘hasMCObjectStreamer’
     bool var_bool = var_llvm_Target->hasMCObjectStreamer();
                                      ^
llvmpy/api.cpp: In function ‘PyObject* llvm_DIBuilder__createMethod(PyObject*, PyObject*)’:
llvmpy/api.cpp:38792:338: error: no matching function for call to ‘llvm::DIBuilder::createMethod(llvm::DIDescriptor&, llvm::StringRef&, llvm::StringRef&, llvm::DIFile&, unsigned int&, llvm::DICompositeType&, bool&, bool&, unsigned int&, unsigned int&, llvm::MDNode*&, unsigned int&, bool&, llvm::Function*&, llvm::MDNode*&)’
         llvm::DISubprogram var_llvm_DISubprogram = var_llvm_DIBuilder->createMethod(var_llvm_DIDescriptor1, var_llvm_StringRef, var_llvm_StringRef1, var_llvm_DIFile1, var_unsigned, var_llvm_DICompositeType1, var_bool, var_bool1, var_unsigned1, var_unsigned2, var_llvm_MDNode, var_unsigned3, var_bool2, var_llvm_Function, var_llvm_MDNode2);
                                                                                                                                                                                                                                                                                                                                                  ^
llvmpy/api.cpp:38792:338: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:598:18: note: llvm::DISubprogram llvm::DIBuilder::createMethod(llvm::DIDescriptor, llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DICompositeType, bool, bool, unsigned int, unsigned int, llvm::DIType, unsigned int, bool, llvm::Function*, llvm::MDNode*)
     DISubprogram createMethod(DIDescriptor Scope, StringRef Name,
                  ^
/usr/include/llvm/DIBuilder.h:598:18: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp:39264:285: error: no matching function for call to ‘llvm::DIBuilder::createMethod(llvm::DIDescriptor&, llvm::StringRef&, llvm::StringRef&, llvm::DIFile&, unsigned int&, llvm::DICompositeType&, bool&, bool&, unsigned int&, unsigned int&, llvm::MDNode*&)’
         llvm::DISubprogram var_llvm_DISubprogram4 = var_llvm_DIBuilder8->createMethod(var_llvm_DIDescriptor9, var_llvm_StringRef8, var_llvm_StringRef9, var_llvm_DIFile9, var_unsigned10, var_llvm_DICompositeType9, var_bool9, var_bool10, var_unsigned11, var_unsigned12, var_llvm_MDNode4);
                                                                                                                                                                                                                                                                                             ^
llvmpy/api.cpp:39264:285: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:598:18: note: llvm::DISubprogram llvm::DIBuilder::createMethod(llvm::DIDescriptor, llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DICompositeType, bool, bool, unsigned int, unsigned int, llvm::DIType, unsigned int, bool, llvm::Function*, llvm::MDNode*)
     DISubprogram createMethod(DIDescriptor Scope, StringRef Name,
                  ^
/usr/include/llvm/DIBuilder.h:598:18: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp:39407:308: error: no matching function for call to ‘llvm::DIBuilder::createMethod(llvm::DIDescriptor&, llvm::StringRef&, llvm::StringRef&, llvm::DIFile&, unsigned int&, llvm::DICompositeType&, bool&, bool&, unsigned int&, unsigned int&, llvm::MDNode*&, unsigned int&)’
         llvm::DISubprogram var_llvm_DISubprogram5 = var_llvm_DIBuilder10->createMethod(var_llvm_DIDescriptor11, var_llvm_StringRef10, var_llvm_StringRef11, var_llvm_DIFile11, var_unsigned13, var_llvm_DICompositeType11, var_bool11, var_bool12, var_unsigned14, var_unsigned15, var_llvm_MDNode6, var_unsigned16);
                                                                                                                                                                                                                                                                                                                    ^
llvmpy/api.cpp:39407:308: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:598:18: note: llvm::DISubprogram llvm::DIBuilder::createMethod(llvm::DIDescriptor, llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DICompositeType, bool, bool, unsigned int, unsigned int, llvm::DIType, unsigned int, bool, llvm::Function*, llvm::MDNode*)
     DISubprogram createMethod(DIDescriptor Scope, StringRef Name,
                  ^
/usr/include/llvm/DIBuilder.h:598:18: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp:39557:320: error: no matching function for call to ‘llvm::DIBuilder::createMethod(llvm::DIDescriptor&, llvm::StringRef&, llvm::StringRef&, llvm::DIFile&, unsigned int&, llvm::DICompositeType&, bool&, bool&, unsigned int&, unsigned int&, llvm::MDNode*&, unsigned int&, bool&)’
         llvm::DISubprogram var_llvm_DISubprogram6 = var_llvm_DIBuilder12->createMethod(var_llvm_DIDescriptor13, var_llvm_StringRef12, var_llvm_StringRef13, var_llvm_DIFile13, var_unsigned17, var_llvm_DICompositeType13, var_bool13, var_bool14, var_unsigned18, var_unsigned19, var_llvm_MDNode8, var_unsigned20, var_bool15);
                                                                                                                                                                                                                                                                                                                                ^
llvmpy/api.cpp:39557:320: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:598:18: note: llvm::DISubprogram llvm::DIBuilder::createMethod(llvm::DIDescriptor, llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DICompositeType, bool, bool, unsigned int, unsigned int, llvm::DIType, unsigned int, bool, llvm::Function*, llvm::MDNode*)
     DISubprogram createMethod(DIDescriptor Scope, StringRef Name,
                  ^
/usr/include/llvm/DIBuilder.h:598:18: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp:39724:341: error: no matching function for call to ‘llvm::DIBuilder::createMethod(llvm::DIDescriptor&, llvm::StringRef&, llvm::StringRef&, llvm::DIFile&, unsigned int&, llvm::DICompositeType&, bool&, bool&, unsigned int&, unsigned int&, llvm::MDNode*&, unsigned int&, bool&, llvm::Function*&)’
         llvm::DISubprogram var_llvm_DISubprogram7 = var_llvm_DIBuilder14->createMethod(var_llvm_DIDescriptor15, var_llvm_StringRef14, var_llvm_StringRef15, var_llvm_DIFile15, var_unsigned21, var_llvm_DICompositeType15, var_bool16, var_bool17, var_unsigned22, var_unsigned23, var_llvm_MDNode10, var_unsigned24, var_bool18, var_llvm_Function2);
                                                                                                                                                                                                                                                                                                                                                     ^
llvmpy/api.cpp:39724:341: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:598:18: note: llvm::DISubprogram llvm::DIBuilder::createMethod(llvm::DIDescriptor, llvm::StringRef, llvm::StringRef, llvm::DIFile, unsigned int, llvm::DICompositeType, bool, bool, unsigned int, unsigned int, llvm::DIType, unsigned int, bool, llvm::Function*, llvm::MDNode*)
     DISubprogram createMethod(DIDescriptor Scope, StringRef Name,
                  ^
/usr/include/llvm/DIBuilder.h:598:18: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp: In function ‘PyObject* llvm_DIBuilder__createClassType(PyObject*, PyObject*)’:
llvmpy/api.cpp:41758:285: error: no matching function for call to ‘llvm::DIBuilder::createClassType(llvm::DIDescriptor&, llvm::StringRef&, llvm::DIFile&, unsigned int&, uint64_t&, uint64_t&, uint64_t&, unsigned int&, llvm::DIType&, llvm::DIArray&, llvm::MDNode*&, llvm::MDNode*&)’
         llvm::DIType var_llvm_DIType2 = var_llvm_DIBuilder->createClassType(var_llvm_DIDescriptor1, var_llvm_StringRef, var_llvm_DIFile1, var_unsigned, var_uint64__t, var_uint64__t1, var_uint64__t2, var_unsigned1, var_llvm_DIType1, var_llvm_DIArray1, var_llvm_MDNode, var_llvm_MDNode2);
                                                                                                                                                                                                                                                                                             ^
llvmpy/api.cpp:41758:285: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:287:21: note: llvm::DICompositeType llvm::DIBuilder::createClassType(llvm::DIDescriptor, llvm::StringRef, llvm::DIFile, unsigned int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType, llvm::DIArray, llvm::DIType, llvm::MDNode*, llvm::StringRef)
     DICompositeType createClassType(DIDescriptor Scope, StringRef Name,
                     ^
/usr/include/llvm/DIBuilder.h:287:21: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp:42025:272: error: no matching function for call to ‘llvm::DIBuilder::createClassType(llvm::DIDescriptor&, llvm::StringRef&, llvm::DIFile&, unsigned int&, uint64_t&, uint64_t&, uint64_t&, unsigned int&, llvm::DIType&, llvm::DIArray&, llvm::MDNode*&)’
         llvm::DIType var_llvm_DIType8 = var_llvm_DIBuilder4->createClassType(var_llvm_DIDescriptor5, var_llvm_StringRef2, var_llvm_DIFile5, var_unsigned4, var_uint64__t6, var_uint64__t7, var_uint64__t8, var_unsigned5, var_llvm_DIType7, var_llvm_DIArray5, var_llvm_MDNode4);
                                                                                                                                                                                                                                                                                ^
llvmpy/api.cpp:42025:272: note: candidate is:
In file included from llvmpy/api.cpp:43:0:
/usr/include/llvm/DIBuilder.h:287:21: note: llvm::DICompositeType llvm::DIBuilder::createClassType(llvm::DIDescriptor, llvm::StringRef, llvm::DIFile, unsigned int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType, llvm::DIArray, llvm::DIType, llvm::MDNode*, llvm::StringRef)
     DICompositeType createClassType(DIDescriptor Scope, StringRef Name,
                     ^
/usr/include/llvm/DIBuilder.h:287:21: note:   no known conversion for argument 11 from ‘llvm::MDNode*’ to ‘llvm::DIType’
llvmpy/api.cpp: In function ‘PyObject* llvm_ExecutionEngine__DeregisterAllTables(PyObject*, PyObject*)’:
llvmpy/api.cpp:45498:31: error: ‘class llvm::ExecutionEngine’ has no member named ‘DeregisterAllTables’
     var_llvm_ExecutionEngine->DeregisterAllTables();
                               ^
llvmpy/api.cpp: In function ‘PyObject* llvm_ExecutionEngine__RegisterTable(PyObject*, PyObject*)’:
llvmpy/api.cpp:46427:31: error: ‘class llvm::ExecutionEngine’ has no member named ‘RegisterTable’
     var_llvm_ExecutionEngine->RegisterTable(var_llvm_Function, var_void2);
                               ^
llvmpy/api.cpp: In function ‘PyObject* llvm_ExecutionEngine__DeregisterTable(PyObject*, PyObject*)’:
llvmpy/api.cpp:46613:31: error: ‘class llvm::ExecutionEngine’ has no member named ‘DeregisterTable’
     var_llvm_ExecutionEngine->DeregisterTable(var_llvm_Function);

I'm going to make the wild guess that something got moved upstream.

Retain LLVM 3.1 support.

The latest release of llvmpy does not support LLVM 3.1.

LLVM 3.1 is a common enough version (namely Ubuntu and Cygwin both provide it as their latest LLVM package) that support should be continued until such time as it is no longer "in-stock".

Compile-time error with numba 0.11.0: "np_datetime.o: requires dynamic R_X86_64_PC32 reloc...'

Hi guys,

I'm having trouble compiling numba 0.11.0 from source. While executing python setup.py build_ext --inplace I hit this linker error:

x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -Wall -Wstrict-prototypes -fPIC -I/home/alistair/build/numba/numba/include -Inumba/pyextensibletype/include -I/home/alistair/.venvs/numba/local/lib/python2.7/site-packages/numpy/core/include -I/home/alistair/.venvs/numba/local/lib/python2.7/site-packages/llvmmath/mathcode/private -I/usr/include/python2.7 -c numba/external/utilities/datetime/np_datetime_strings.c -o build/temp.linux-x86_64-2.7/numba/external/utilities/datetime/np_datetime_strings.o
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/numba/external/utilities/utilities.o build/temp.linux-x86_64-2.7/numba/external/utilities/datetime/np_datetime.o build/temp.linux-x86_64-2.7/numba/external/utilities/datetime/np_datetime_strings.o -o /home/alistair/build/numba/numba/external/utilities/utilities.so
/usr/bin/ld: error: build/temp.linux-x86_64-2.7/numba/external/utilities/datetime/np_datetime.o: requires dynamic R_X86_64_PC32 reloc against 'PyDatetimeArrType_Type' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: hidden symbol 'PyDatetimeArrType_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyDatetimeArrType_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyArray_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyArray_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyTimedeltaArrType_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyTimedeltaArrType_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyArray_Type' is not defined locally
/usr/bin/ld: error: hidden symbol 'PyArray_Type' is not defined locally
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

I'm running Ubuntu 13.04 (3.8.0-31-generic) and using Python 2.4.7 and GCC 4.8.1. I compiled LLVM 3.3 from source in a temporary directory, using REQUIRES_RTTI=1.

I am trying to install numba in a clean virtualenv with no system site packages, containing:

Cython==0.19.2
argparse==1.2.1
cffi==0.7.2
distribute==0.6.34
ipython==1.1.0
llvmmath==0.1.1
llvmpy==0.12.0-55-g18d3b48
nose==1.3.0
numpy==1.9.0.dev-84c52d8
pycparser==2.10
wsgiref==0.1.2

Both llvmpy and llvmmath seem to be installed properly and working fine - they pass all of their respective nose tests. There's a single failure with numpy somewhere in test_io, nothing that looks critically important.

What's more, using the same virtualenv I am able to build and install numba 0.10.2 successfully, and it passes almost all of its nose tests (I get two failures, one in test_datetime and one in test_nosource.

Any ideas where the problem might lie?

Confusing project description/URL on github

llvmpy has its own mailing list, even though it arguably would make sense to reuse existing llvm-py mailing list to preserve knowledge continuity.

However, llvmpy's project description is rather confusing "My fork of the llvm-py svn repository" and points to http://www.mdevan.org/llvm-py/index.html which simply doesn't have any references to new project. Please consider updating that info.

BUG: iterator_to_pylist_deref and iterator_to_pylist leak 1 reference

llvmpy/include/llvm_binding/extra.h

pycapsule_new calls PyCapsule_New which returns a NEW reference
PyList_Append calls Py_INCREF implicitly
Original reference must have Py_DECREF called

diff:

--- e:\llvmpy-llvmpy-0.12.1-1-gc199881_foo\llvmpy-llvmpy-c199881\llvmpy\include\llvm_binding\extra.h    Mon Nov 18 16:59:01 2013
+++ llvmpy\include\llvm_binding\extra.h Wed Jan 08 16:14:10 2014
@@ -184,26 +184,28 @@
 PyObject* iterator_to_pylist_deref(iterator begin, iterator end,
                              const char *capsuleName, const char *className)
 {
     PyObject* list = PyList_New(0);
     for(; begin != end; ++begin) {
         PyObject* cap = pycapsule_new(&*begin, capsuleName, className);
         PyList_Append(list, cap);
+        Py_DECREF(cap);
     }
     return list;
 }

 template<class iterator>
 PyObject* iterator_to_pylist(iterator begin, iterator end,
                              const char *capsuleName, const char *className)
 {
     PyObject* list = PyList_New(0);
     for(; begin != end; ++begin) {
         PyObject* cap = pycapsule_new(*begin, capsuleName, className);
         PyList_Append(list, cap);
+        Py_DECREF(cap);
     }
     return list;
 }

 template<class iplist>
 PyObject* iplist_to_pylist(iplist &IPL, const char * capsuleName,
                            const char* className){

Installation issue on Mac

I have LLVM-3.2 installed, and I am trying to install LLVMPY, but I get the attached error. It seems like it's looking for /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/c++config.h but there is no such file.

Update : I found the headers in this location:
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/x86_64-apple-darwin9/bits/

[[ ---- part of error message ---]]

file llvmpy.py (for module llvmpy) not found
file llvmpy/_capsule.py (for module llvmpy._capsule) not found
file llvmpy/_api.py (for module llvmpy._api) not found
running build_ext
building 'llvmpy._api' extension
gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -DNDEBUG -g -O3 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/Users/kamesh/Code/LLVM/include -Illvmpy/include -I/Library/Frameworks/EPD64.framework/Versions/7.3/include/python2.7 -c llvmpy/api.cpp -o build/temp.macosx-10.5-x86_64-2.7/llvmpy/api.o
In file included from /Users/kamesh/Code/LLVM/include/llvm/Support/DataTypes.h:37,
from /Users/kamesh/Code/LLVM/include/llvm/Support/type_traits.h:20,
from /Users/kamesh/Code/LLVM/include/llvm/Support/Casting.h:18,
from llvmpy/include/llvm_binding/conversion.h:2,
from llvmpy/api.cpp:5:
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/cmath:49:28: error: bits/c++config.h: No such file or directory
In file included from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/stl_algobase.h:69,
from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/algorithm:65,
from /Users/kamesh/Code/LLVM/include/llvm/ADT/StringRef.h:15,
from llvmpy/include/llvm_binding/conversion.h:3,
from llvmpy/api.cpp:5:
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/iosfwd:45:29: error: bits/c++locale.h: No such file or directory
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/iosfwd:46:25: error: bits/c++io.h: No such file or directory
In file included from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/memory:54,
from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/stl_tempbuf.h:64,
from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/stl_algo.h:65,
from /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/algorithm:68,
from /Users/kamesh/Code/LLVM/include/llvm/ADT/StringRef.h:15,
from llvmpy/include/llvm_binding/conversion.h:3,
from llvmpy/api.cpp:5:
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/allocator.h:52:31: error: bits/c++allocator.h: No such file or directory

Latest release of LLVM breaks llvmpy

The important part of the error from gcc is as follows:

llvm/extra.cpp:296:14: error: ‘class llvm::TargetMachine’ has no member named ‘getTargetData’
llvm/extra.cpp:301:32: error: ‘class llvm::TargetMachine’ has no member named ‘getTargetData’
llvm/extra.cpp: In function ‘LLVMOpaqueTargetData* LLVMTargetMachineGetTargetData(LLVMTargetMachineRef)’:

Looks like there's an API call to a member function that no longer exists.

I'm running LLVM 3.2 on a MacBook 4,1 with Arch Linux.

How to get float/double from ConstantFP?

How to retrieve the double or float value from ConstantFP (actually Constant) class. It seems there is no interface for such requirement.

By the way, how do you generate the llvmpy/api.cpp and llvmpy/api/llvm/init.py? By manual or some automatical tool? I'm using llvmpy-0.11.2 which is the most recent version in the official website.

Thanks!

Dependency on Minivect

Seems this line leads to a circular dependency of Numba & llvmpy. Is there a way to resolve the map of npy_intp to LLVM without a call into minivect?

https://github.com/llvmpy/llvmpy/blob/master/llvm_cbuilder/shortnames.py#L16

Tests segfault on armv7l architecture

Hi, I have packaged llvmpy for Fedora Linux. Fedora now has armv7l as one of its primary architectures, that means that all packages are build on it by default.

I have noticed that the tests in llvm.test() in version 0.12.0 fail with segmentation fault in this particular architecture.

the problem seems to be in test_cpu_support2

   $ arch
   armv7l
   $ nosetests -v /opt/lib/python2.7/site-packages
   (...)   
   test_bitcode (llvm.test_llvmpy.TestAsm) ... ok
   test_atomic_cmpxchg (llvm.test_llvmpy.TestAtomic) ... ok
   test_atomic_ldst (llvm.test_llvmpy.TestAtomic) ... ok
   test_atomic_rmw (llvm.test_llvmpy.TestAtomic) ... ok
   test_align (llvm.test_llvmpy.TestAttr) ... ok
   test_cpu_support2 (llvm.test_llvmpy.TestCPUSupport) ... '-sse3' is not a   recognized feature for this target (ignoring feature)
   '-sse41' is not a recognized feature for this target (ignoring feature)
   '-sse42' is not a recognized feature for this target (ignoring feature)
   '-avx' is not a recognized feature for this target (ignoring feature)
   '-sse3' is not a recognized feature for this target (ignoring feature)
   '-sse41' is not a recognized feature for this target (ignoring feature)
   '-sse42' is not a recognized feature for this target (ignoring feature)
   '-avx' is not a recognized feature for this target (ignoring feature)
   Stack dump:
   0.   Running pass 'ARM Machine Code Emitter' on function '@mysin'
   Segmentation fault

I have set up a virtual machine to make this test, I do not own armv7l hardware my self. I have followed to instructions here https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU to setup the VM.

Empty lib path causes problem to MS linker

Hi,

I'm trying to build llvmpy. I compiled llvm and clang with MSVS 2010, and when trying to build llvmpy I get this error:

...
c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH: /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PCbuild LLVMAnalysis.lib LLVMAsmParser.lib LLVMAsmPrinter.lib LLVMBitReader.lib LLVMBitWriter.lib LLVMCodeGen.lib LLVMCore.lib LLVMExecutionEngine.lib LLVMInstCombine.lib LLVMInstrumentation.lib LLVMInterpreter.lib LLVMipa.lib LLVMipo.lib LLVMJIT.lib LLVMLinker.lib LLVMMC.lib LLVMMCParser.lib LLVMScalarOpts.lib LLVMSelectionDAG.lib LLVMSupport.lib LLVMTarget.lib LLVMTransformUtils.lib LLVMVectorize.lib LLVMX86AsmParser.lib LLVMX86AsmPrinter.lib LLVMX86CodeGen.lib LLVMX86Desc.lib LLVMX86Info.lib LLVMX86Utils.lib Advapi32.lib Shell32.lib /EXPORT:init_core build\temp.win32-2.7\Release\llvm/_core.obj build\temp.win32-2.7\Release\llvm/wrap.obj build\temp.win32-2.7\Release\llvm/extra.obj /OUT:build\lib.win32-2.7\llvm\_core.pyd /IMPLIB:build\temp.win32-2.7\Release\llvm\_core.lib /MANIFESTFILE:build\temp.win32-2.7\Release\llvm\_core.pyd.manifest /MANIFEST
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

LINK : fatal error LNK1146: no argument specified with option '/LIBPATH:'
error: command '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.exe"' failed with exit status 1146

full log is here: https://gist.github.com/77015497439d133b2d74

So it looks like at some point empty switch is added to command line (/LIBPATH: ) which causes problem with linker.

Any ideas how to resolve this?

Thanks

llvmpy library contains shebangs

The *.py files under llpython contain a shebang (#!/usr/bin/env python)

Shebang should be used only for scripts that need direct execution. Library modules shouldn't have shebang as they shouldn't be executable directly by the user.

PassManager support for llvmpy

having some native python bindings for llvm's pass manager would be great for people wanting to experiment with adding custom compiler passes.

http://llvm.org/docs/WritingAnLLVMPass.html

Documentation Issue

I am not quite sure if it is intended to report issues with the project's documentation. I thought I'd post it here anyway since it is also linked by the project website. In case that's wrong, feel free to correct me.

https://groups.google.com/a/continuum.io/forum/#!topic/llvmpy/jE4UjoAxikA
The link goes to a topic in the appropriate Google Group. The following is a copy of the thread's content.

I stumbled upon an issue with the Kaleidoscope tutorial linked on the main page.

def main():
  # Set up the optimizer pipeline. Start with registering info about how the
  # target lays out data structures.
  g_llvm_pass_manager.add(g_llvm_executor.target_data)
  # Do simple "peephole" optimizations and bit-twiddling optzns.
  #g_llvm_pass_manager.add(PASS_INSTRUCTION_COMBINING) -- pass not found
  g_llvm_pass_manager.add(PASS_INSTCOMBINE) # -- used instead

  # Reassociate expressions.
  g_llvm_pass_manager.add(PASS_REASSOCIATE)
  # Eliminate Common SubExpressions.
  g_llvm_pass_manager.add(PASS_GVN)
  # Simplify the control flow graph (deleting unreachable blocks, etc).
  #g_llvm_pass_manager.add(PASS_CFG_SIMPLIFICATION) -- pass not found
  g_llvm_pass_manager.add(PASS_SIMPLIFYCFG) # -- used instead

  g_llvm_pass_manager.initialize()

I'm on x86_64 GNU/Linux using llvm-3.1.src.tar.gz on Python 2.7.3. Some of the passes were not found so I replaced them with what I think are the updated ones, chosen from this list:

from llvm.passes import _dump_all_passes
for x in _dump_all_passes():
    print("%s:\n%s\n" % x)

Still, PASS_INSTCOMBINE does not seem to optimize anything. I expected the additions to be combined into one single multiplication:

ready> def foo(x) x+x+x+x+x
Read a function definition:
define double @foo(double %x) {
entry:
  %addtmp = fadd double %x, %x
  %addtmp1 = fadd double %addtmp, %x
  %addtmp2 = fadd double %addtmp1, %x
  %addtmp3 = fadd double %addtmp2, %x
  ret double %addtmp3
}

Instead, the pass does not seem to run at all. Anything I am doing wrong here? Any way to make LLVM more verbose?

Kind Regards

Installation problem

Hi!
I'm trying to install llvmpy on gentoo linux and I've got some errors during installation. I would be very thankfull for any help.
input:
git clone https://github.com/llvmpy/llvmpy.git
cd llvmpy
python setup.py install

output:
LLVM version = 3.1
Generate intrinsic IDs
Using PTX
llvm-config: unknown component name: ptx
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/llvm
copying llvm/init.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/core.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/_util.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/_intrinsic_ids.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/ee.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/test_llvmpy.py -> build/lib.linux-x86_64-2.7/llvm
copying llvm/passes.py -> build/lib.linux-x86_64-2.7/llvm
running build_ext
building 'llvm._core' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/llvm
x86_64-pc-linux-gnu-g++ -pthread -fPIC -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/usr/include -I/usr/include -I/usr/include/python2.7 -c llvm/_core.cpp -o build/temp.linux-x86_64-2.7/llvm/_core.o
llvm/core.cpp: In function ‘PyObject* wLLVMInitializePTXTarget(PyObject, PyObject)’:
llvm/_core.cpp:919:1: error: ‘LLVMInitializePTXTarget’ was not declared in this scope
llvm/core.cpp: In function ‘PyObject* wLLVMInitializePTXTargetInfo(PyObject, PyObject)’:
llvm/_core.cpp:920:1: error: ‘LLVMInitializePTXTargetInfo’ was not declared in this scope
llvm/core.cpp: In function ‘PyObject* wLLVMInitializePTXTargetMC(PyObject, PyObject)’:
llvm/_core.cpp:921:1: error: ‘LLVMInitializePTXTargetMC’ was not declared in this scope
llvm/core.cpp: In function ‘PyObject* wLLVMInitializePTXAsmPrinter(PyObject, PyObject)’:
llvm/_core.cpp:922:1: error: ‘LLVMInitializePTXAsmPrinter’ was not declared in this scope
error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1

Installaion failed

https://github.com/samueljohn/homebrew-python/issues/68

Where can I find the missing file?

ImportError Python2.7 / LLVM3.2 / 64bit Ubuntu Linux

I installed LLVM3.2 from here. Checked out llvmpy from GitHub, and did git checkout 0.10.1. Then I ran

LLVM_CONFIG_PATH=/usr/bin/llvm-config-3.2 python setup.py build
sudo LLVM_CONFIG_PATH=/usr/bin/llvm-config-3.2 python setup.py install

In IPython, I get

In [1]: import llvm
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/home2/hilboll/<ipython-input-1-d06f8cf4fcbe> in <module>()
----> 1 import llvm

/usr/local/lib/python2.7/dist-packages/llvm/__init__.py in <module>()
      7 
      8 from weakref import WeakValueDictionary
----> 9 from . import _core
     10 
     11 #===----------------------------------------------------------------------===

ImportError: /usr/local/lib/python2.7/dist-packages/llvm/_core.so: undefined symbol: _ZTIN4llvm13ImmutablePassE

Support truediv in IntegerValue (Python 3 compatibility)

When porting Python 2 to 3, the division operator is mapped to __truediv__ if from __future__ import division is used. This patch maps __div__ to __truediv__.

Ps.- In the long rung, it would be nice to implement the correct semantics for __div__, __truediv__ and __floordiv__.

diff --git a/llvm_cbuilder/builder.py b/llvm_cbuilder/builder.py
index 917b37e..94725a5 100644
--- a/llvm_cbuilder/builder.py
+++ b/llvm_cbuilder/builder.py
@@ -988,6 +988,9 @@ class IntegerValue(OperatorMixin):
         else:
             return self._temp(self.parent.builder.sdiv(self.value, rhs.value))

+    def __truediv__(self, rhs):
+        return self.__div__(rhs)
+
     def __mod__(self, rhs):
         if self.unsigned:
             return self._temp(self.parent.builder.urem(self.value, rhs.value))

Typo in quickstart instructions?

It seems that llvm's configure script has no '--mar' option but that flag is given in the quickstart. Configuring llvm with just --enable-pic seems to work fine.

Please support (upcoming) llvm 3.3

Hi, I would like to create an RPM of llvmpy to be included in Fedora. But Fedora ships a release candidates of llvm 3.3 (It is needed by some new features of Mesa). The current released version of llvmpy doesn't work with 3.3. It would be great to have branch of llvmpy that works with llvm 3.3

Another missing symbol (__ZTIN4llvm13ImmutablePassE)

I'm on OSX 10.8.2, and I'm using llvm-3.2 from macports. Everything seems to compile fine, but when I attempt to import llvm (i.e. import llvm from Python), I get the following error:

----> 1 import llvm

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/llvm/__init__.py in <module>()
      7 
      8 from weakref import WeakValueDictionary
----> 9 from . import _core
     10 
     11 #===----------------------------------------------------------------------===

ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/llvm/_core.so, 2): Symbol not found: __ZTIN4llvm13ImmutablePassE
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/llvm/_core.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/llvm/_core.so

llvm was compiled with --enable-pic as well as with RTTI, so I think this missing symbol is somehow different from the other.

TestNativeAsm missing att env

In test_llvmpy.py

class TestNativeAsm(unittest.TestCase):

    def test_asm(self):
        m = Module.new('module1')

        foo = m.add_function(Type.function(Type.int(),
                                       [Type.int(), Type.int()]),
                         name="foo")
        bldr = Builder.new(foo.append_basic_block('entry'))
        x = bldr.add(foo.args[0], foo.args[1])
        bldr.ret(x)

        att_syntax = m.to_native_assembly()
        os.environ["LLVMPY_OPTIONS"] = "-x86-asm-syntax=intel"
        lc.parse_environment_options(sys.argv[0], "LLVMPY_OPTIONS")
        intel_syntax = m.to_native_assembly()

        self.assertNotEqual(att_syntax, intel_syntax)

tests.append(TestNativeAsm)

os.environ["LLVMPY_OPTIONS"] = "-x86-asm-syntax=att" is missing for att_syntax and will lead the test fail.

Python 3.2.3 invalid exception syntax.

when installing on python 3.2.3 the follow error crashes the installation:

copying build/lib.linux-i686-3.2/llvm/_intrinsic_ids.py -> /usr/local/lib/python3.2/dist-packages/llvm
byte-compiling /usr/local/lib/python3.2/dist-packages/llvm/_intrinsic_ids.py to _intrinsic_ids.cpython-32.pyc
byte-compiling /usr/local/lib/python3.2/dist-packages/llvm_cbuilder/translator.py to translator.cpython-32.pyc
  File "/usr/local/lib/python3.2/dist-packages/llvm_cbuilder/translator.py", line 26
    except Exception, e:
                    ^
SyntaxError: invalid syntax

running install_egg_info
Removing /usr/local/lib/python3.2/dist-packages/llvmpy-0.9.1.egg-info
Writing /usr/local/lib/python3.2/dist-packages/llvmpy-0.9.1.egg-info

This seems to just be caused my using a python 2 only syntax for throwing the exception. This was changed in python3 via pep-3110 (http://docs.python.org/3.0/whatsnew/2.6.html#pep-3110).

MCJIT causes access error on win32 64-bit

Caused by compatibility between windows version?

Union Type support

The LLVM IR appears to support unions, but these bindings did not seem to support them.

I were writing C FFI for my language when I noticed this. Going to get around the issue by calculating size of every record, allocate that record and cast between them. There doesn't seem to be nicer way around it with union type missing.

That workaround has good chances to introduce some C-ABI issues. I have been ignoring machine specific details because LLVM took care of it all.

'undefined reference to'

I am trying to build llvmpy and are getting lots of 'undefined reference to' errors. Example:

build\temp.win32-2.7\Release\llvmpy\api.o:api.cpp:(.text+0xb539): undefined reference to `llvm::Linker::releaseModule()'

Here is the full errors list:

http://www.ipaste.eu/view?id=4861

Exception in `ExecutionEngine.del` on exit

I'm getting the following error messages when running the dabeaz/bitey examples.

Exception TypeError: "'NoneType' object is not callable" in <bound method ExecutionEngine.__del__ of <llvm.ee.ExecutionEngine object at 0x7fd912e3be10>> ignored

Exception AttributeError: "'NoneType' object has no attribute 'LLVMDisposeExecutionEngine'" in <bound method ExecutionEngine.__del__ of <llvm.ee.ExecutionEngine object at 0x2a5c6d0>> ignored

The error pops up right before the Python interpreter exits.

llvmpy links to incorrect python library

I'm not sure if this is the fault of the llvmpy install script, or my python installation

Importing llvmpy on my mac (os X 10.7) crashes python with
Fatal Python error: Interpreter not initialized (version mismatch?)

I tracked this down to the python library that _core.so links against:

otool -L _core.so 
_core.so:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
    /usr/lib/libffi.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)

however, the version of python I use (and built llvmpy with) is at /opt/local/bin/python. The problem goes away if I run

install_name_tool -change /Library/Frameworks/Python.framework/Versions/2.7/Python /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python _core.so

GIT variable is undefined

This variable is used in llvmpy/_version.py but is not imported nor declared anywhere.

Modifying Instruction List

Hi,
Looking through the C++ API it seems that you must modify the underlying list. I've been reading through the code and so far what I gather is that getInstList() is read-only. Basically what I would like to do is something like ReplaceInstWithInst() from the C++ API.

How do I go about modifying it with llvmpy?

Thanks

LLVMModule is not hashable (Python 3)

In Python 3, LLVMModule is not hashable and therefore cannot be used as a dictionary key as done by Numba.

Support LLVM configured without --disable-libffi

This is just a minor inconvenience, but needing to rebuild LLVM greatly increases the time required to experiment with llvmpy and the error message is not so helpful at indicating what the problem actually is.

https://groups.google.com/d/msg/llvm-py/VVrDmB5K1yo/hZ_f3Syie3YJ

printf is throwing a Segmentation Fault on Ubuntu.

I receive a segmentation fault (core dumped) ... error when attempting to run the following bit of code:

printf = module.add_function(Type.function(C.void, []), 'printf')
cb = CBuilder(printf)
fmt = cb.constant_string("Test")
cb.printf(fmt)
cb.ret()
cb.close()

exe = CExecutor(module)
func = exe.get_ctype_function(printf, 'void')
func()

The error seems to stem from the actual func() call. I've tried to double check the example in the tests directory and the only difference I can find is that I lack a call to module.verify(). Is this a requirement to run commands from the C helper files?

If so, it seems a bit strange since (as far as I understand) the module.verify() command signals an end which is not what I want.

Or is there another reason for this error?

Python 2.7.3
Ubuntu 12.04.3

Fix LLVM build README

README in repo and llvmpy.pydata.org have a different LLVM build instruction. And neither is accurate.

"Development" documentation links points to 0.9

The documentation page: http://www.llvmpy.org/doc.html

Points to "Development", "Version 0.10.2" and "Version 0.9". When I click on "Development" I get to the docs of 0.9, though, which doesn't seem to be the right thing.

llpython 2.6 bug NotImplementedError: LLVMTranslator.op_JUMP_IF_FALSE

This problem shows up when running Numba in python2.6.

The full stacktrace:

Traceback (most recent call last):
  File "runtests.py", line 4, in <module>
    import numba
  File "/Users/sklam/dev/numba/numba/__init__.py", line 53, in <module>
    from . import decorators
  File "/Users/sklam/dev/numba/numba/decorators.py", line 24, in <module>
    context.intrinsic_library = default_intrinsic_library(context)
  File "/Users/sklam/dev/numba/numba/intrinsic/__init__.py", line 31, in default_intrinsic_library
    intrlib.add(fncls)
  File "/Users/sklam/dev/numba/numba/intrinsic/intrinsic.py", line 79, in add
    self.implement(intr())
  File "/Users/sklam/dev/numba/numba/intrinsic/intrinsic.py", line 89, in implement
    intr.implementation(lfunc.module, lfunc)
  File "/Users/sklam/dev/numba/numba/intrinsic/string_intrinsic.py", line 51, in implementation
    llvm_function = lfunc)
  File "/Users/sklam/dev/llvmpy/llpython/byte_translator.py", line 184, in translate
    ret_val = self.visit(flow)
  File "/Users/sklam/dev/llvmpy/llpython/bytecode_visitor.py", line 179, in visit
    for i, op, _, arg, args in flow[block])
  File "/Users/sklam/dev/llvmpy/llpython/bytecode_visitor.py", line 179, in <genexpr>
    for i, op, _, arg, args in flow[block])
  File "/Users/sklam/dev/llvmpy/llpython/bytecode_visitor.py", line 192, in visit_op
    *new_args)
  File "/Users/sklam/dev/llvmpy/llpython/bytecode_visitor.py", line 19, in visit_op
    ret_val = method(i, op, arg, *args, **kws)
  File "/Users/sklam/dev/llvmpy/llpython/byte_translator.py", line 452, in op_JUMP_IF_FALSE
    raise NotImplementedError("LLVMTranslator.op_JUMP_IF_FALSE")

Support llvm 3.3

Apple has been shipping llvm 3.3 by default with xcode for a while now, so it would be nice if llvmpy worked with llvm 3.3 too. Is this supposed to work already? Is llvm 3.3 support in the roadmap?

llvm.Cacheable's not being garbage collected quickly enough to keep pace with LLVM allocator?

When running the Numba test suite, I see a lot of objects of the wrong types coming from llvm-py. For example:

Traceback (most recent call last):
  File "/home/jriehl/git/numba/tests/test_forloop.py", line 80, in test_compiled_for_loop_fn_3
    ret_type = 'i')(for_loop_fn_3)
  File "/home/jriehl/git/numba/numba/decorators.py", line 74, in _numba_compile
    t.translate()
  File "/home/jriehl/git/numba/numba/translate.py", line 585, in translate
    self.build_phi_nodes(self.crnt_block)
  File "/home/jriehl/git/numba/numba/translate.py", line 688, in build_phi_nodes
    (type(phi), lc.PHINode))
AssertionError: Intermittent llvm-py error encountered (builder.phi() result type was <class 'llvm.core.BasicBlock'>, not <class 'llvm.core.PHINode'>).

I've chased the llvm-py constructors to the llvm.Cacheable parent class which uses a metaclass to keep a cache of values. The cache is implemented as a WeakValueDictionary, which maps from pointers received via llvm-c to Python wrapper objects. When a Python wrapper object is garbage collected, the weak reference in the cache should be quietly removed, preventing collisions.

This is the first time I've seen WeakValueDictionary, so I did some experiments:

>>> from weakref import WeakValueDictionary
>>> cache = WeakValueDictionary()
>>> class Thingy (object):
...  pass
... 
>>> t = Thingy()
>>> cache[22] = t
>>> cache.get(22)
<__main__.Thingy object at 0x7fcd3920cc50>
>>> del t
>>> cache.get(22)
<__main__.Thingy object at 0x7fcd3920cc50>
>>> cache.get(22)
<__main__.Thingy object at 0x7fcd3920cc50>
>>> import gc
>>> cache.get(22)
<__main__.Thingy object at 0x7fcd3920cc50>
>>> gc.collect()
0
>>> cache.get(22)
>>>

Based on this experiment, I'm guessing that llvm-c is returning new LLVM object addresses that are still mapped in _ObjectCache.__instances. Ideally, llvm-py should take steps to avoid this cache collision, and save its users the confusion caused by having llvm.core.Module.new() return a basic block instance. What is worse is this also implies that cached objects contain unsafe pointers to either garbage data or the wrong data structure entirely.

I've tried the workaround of adding a call to gc.collect(). This was still not aggressive enough for the Numba test suite, so I've had to manually clear the llvm-py object cache:

from llvm import _ObjectCache, WeakValueDictionary
setattr(_ObjectCache, '_ObjectCache__instances', WeakValueDictionary())

LLVM opimization passes not working right and crashing.

Firstly, sorry about this as i believe it may be something wrong on my end but i don't know where else to ask such a thing in absence of an llvmpy forum or irc channel so apologies.

I am trying to follow along with the kaleidoscope tutorial and am having problems with part 4.

Firstly i have tried llvmpy 0.9 and the very latest git pulls and i have the same issues. I have run llvm.test() and it all passes.

However when i go to do this line g_llvm_pass_manager.add(g_llvm_executor.target_data).
it causes a crash with a massive error log. I have made a short pastebin link, nothing special just cut out the llvm globals setup and added the crash message to the bottom as it is quite lengthy.

http://pastebin.com/gFHEv0jA

Whats going on here? it seems to say that the pass manager cannot take ownership of the pass cause someone else does?

Also i cannot directly import the passes themselves i have to import * from the passes module. Did i compile llvm incorrectly? I am using llvm3.2, python 2.7, ubuntu 12.04 x86_64.

llvmpy.org and pypi show outdated versions of llvmpy

The links in both llvmpy.oth and pypi.python.org point to release 0.11.2, but there is a newer 0.12 release.

documentation to help people contribute

Hello, I'm interested in contributing (specifically, I want to add support for the MC* llvm functionality, especially the disassembler stuff). If possible, could someone add some documentation on how the code generation stuff works (I couldn't find any info on this in the website documentation)? I've been reading through the code in llvmpy/src and llvmpy/gen but there aren't many comments. I'll probably figure it out eventually, but any summary from a core developer of how all this code fits together would really help me a lot. Thanks.

Structure support in llpython.

LLPython should be enhanced to support structures. Structure datatypes may be represented using named tuples, or possibly reuse ctypes.Structure class definitions.

build llvmpy with MSVC 10.0 with link error

llvm version which I tested is 3.2.
The link error says that it missing "~RTDyldMemoryManager(void)" function.
I add LLVMObject LLVMRuntimeDyld to the libs list of llvm-config-win32.py. Then it solve the problem.

cannot build against Python 2.6

When building against Python 2.6, I get:
llvm/_core.cpp:74: error: 'PyCapsule_GetPointer' was not declared in this scope

The 0.8.1 tag was working fine against Python 2.6, and I we should still support Python 2.6.
The earlier version had a LLVM_PY_USE_PYCAPSULE macro to handle this, which
is no longer present in the master.

Website is not up to date

I can see the release 0.12.1 here:
https://github.com/llvmpy/llvmpy/releases
but on the website, here is no reference of this release:
http://www.llvmpy.org/download.html#
(and on the right side, it is only about the 0.11.2 release).

The website should be updated (or the reference to the latest release removed).

Pypi package does not include "tools" directory

The tools directory is not included in the pypi package, but it is referenced in setup.py in auto_intrinsic_gen().

Python 3 compatibility broken (PyUnicode_AsUTF8 declaration)

Current git tree is broken this way with python3.2.3 (what's the status of llvm python3 compatibility support / testing?):

file llvmpy.py (for module llvmpy) not found
file llvmpy/_capsule.py (for module llvmpy._capsule) not found
file llvmpy/_api.py (for module llvmpy._api) not found
running build_ext
building 'llvmpy._api' extension
gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/usr/local/include -Illvmpy/include -I/usr/include/python3.2mu -c llvmpy/api.cpp -o build/temp.linux-x86_64-3.2/llvmpy/api.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from /usr/include/python3.2mu/Python.h:8:0,
from llvmpy/api.cpp:2:
/usr/include/python3.2mu/pyconfig.h:1182:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default]
In file included from /usr/include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h:40:0,
from /usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h:414,
from /usr/include/c++/4.7/cstring:43,
from llvmpy/api.cpp:1:
/usr/include/features.h:164:0: note: this is the location of the previous definition
In file included from /usr/include/python3.2mu/Python.h:8:0,
from llvmpy/api.cpp:2:
/usr/include/python3.2mu/pyconfig.h:1204:0: warning: "_XOPEN_SOURCE" redefined [enabled by default]
In file included from /usr/include/c++/4.7/x86_64-linux-gnu/bits/os_defines.h:40:0,
from /usr/include/c++/4.7/x86_64-linux-gnu/bits/c++config.h:414,
from /usr/include/c++/4.7/cstring:43,
from llvmpy/api.cpp:1:
/usr/include/features.h:166:0: note: this is the location of the previous definition
In file included from llvmpy/api.cpp:5:0:
llvmpy/include/llvm_binding/conversion.h: In function ‘int py_str_to(PyObject*, llvm::StringRef&)’:
llvmpy/include/llvm_binding/conversion.h:40:48: error: ‘PyUnicode_AsUTF8’ was not declared in this scope

Cannot compile against current LLVM (3.2) - PTX removed

This has broken since Aug 13th.

On that day LLVMPY could be built against LLVM 3.2svn

To replicate:

checkout LLVM from svn trunk
build llvmpy against it

platform detected: mingw 32

building 'llvm._core' extension
j:\mingw\bin\gcc.exe -mdll -O -Wall -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/usr/include -Iz:/numba/llvm/install/include -IV:\python-dist\2.7.2-dev\python27\include -IV:\python-dist\2.7.2-dev\python27\PC -c llvm/_core.cpp -o build\temp.win32-2.7\Release\llvm_core.o

llvm/core.cpp: In function 'PyObject* wLLVMInitializePTXTarget(PyObject, PyObject)':
llvm/_core.cpp:900:1: error: 'LLVMInitializePTXTarget' was not declared in this scope
llvm/core.cpp: In function 'PyObject* wLLVMInitializePTXTargetInfo(PyObject, PyObject)':
llvm/_core.cpp:901:1: error: 'LLVMInitializePTXTargetInfo' was not declared in this scope
llvm/core.cpp: In function 'PyObject* wLLVMInitializePTXTargetMC(PyObject, PyObject)':
llvm/_core.cpp:902:1: error: 'LLVMInitializePTXTargetMC' was not declared in this scope
llvm/core.cpp: In function 'PyObject* wLLVMInitializePTXAsmPrinter(PyObject, PyObject)':
llvm/_core.cpp:903:1: error: 'LLVMInitializePTXAsmPrinter' was not declared in this scope
error: command 'gcc' failed with exit status 1

Superficial Diagnosis:

support for PTX machine was added to llvmpy.

But PTX back-end was removed from LLVM 2 months ago.

This is the commit that removed PTX from LLVM:

https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PTX/InstPrinter/?view=log

Modified Thu May 24 16:38:21 2012 CDT (2 months, 3 weeks ago) by jholewinski https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PTX/InstPrinter/?view=log

Remove the PTX back-end and all of its artifacts (triple, etc.)

This back-end was deprecated in favor of the NVPTX back-end.

NV_CONTRIB