There's no clear pattern in the missing symbols. I'm pretty sure that I haven't used LTO for python itself, apart from a some tests with an early version llvm-gcc where using LTO for building python used to crash the compiler :-)īTW. I've used -O4 for extensions in the past (which until recently implied LTO) and that worked fine. However, if there is something I can help (e.g., running benchmarks with different compilation settings), let me know.Īuthor: Ronald Oussoren (ronaldoussoren) * Personally I'm interested in LTO because I want to obtain whole-program LLVM bitcode files (for use in a research project about instrumentation). However, that data point refers to GCC's LTO, not LLVM's. I don't know about Mac OS, but on Ubuntu, LTO and PGO apparently make Python around 10% faster (see #17781). Potentially supporting LTO seems to me to be more of a feature than a bug so I think should be considered a 3.5 issue, at least initially. It certainly would be an interesting project for someone with the interest and time. One would need to look at things like what effect these all have on memory and shared memory footprints as well as cpu resources and real time, with and without LTO and/or other optimizations. And there are at least three separate current build configurations to consider on OS X: unshared, -enable-shared, -enable-framework. For example, I could imagine that LTO might be have more impact if the standard library extension modules were statically linked, e.g. Also, some thought would need to go into and tests developed to see what the performance trade-offs are. Just as an experiment (using the 3.4 branch and the Xcode 5.1 clang), the list of unique symbols not found during the test dlopen in setup.py when using -flto:ĭo we know if anyone has tried to use LTO with a Python build previously? I've never tried it myself and there certainly could be ld and/or dyld differences on OS X. In particular, Clang finishes successfully and does produce shared object files they just don't seem to be loadable. However, the errors I get are rather different than #20767. I am indeed using Clang 3.4 (both the one that ships with Mac OS, and a version compiled from the sources). What is your clang version? See also issue #20767. *** WARNING: renaming "_scproxy" since importing it failed: dlopen(build/lib.macosx-10.9-x86_64-3.5/_scproxy.so, 2): Symbol not found: _Py_NoneStruct usr/bin/clang -bundle -undefined dynamic_lookup -flto build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.5/_scproxy.so -framework SystemConfiguration -framework CoreFoundation cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o I/usr/local/include -I./cpython/Include -I./cpython-lto-build -c. usr/bin/clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -flto -I./cpython/Include -I. On Mac, I receive the following error (similar for other extensions): On Linux, the above builds correctly and passes most of the test suite. The RANLIB variable should not be needed on Mac, because its toolchain does not need a GOLD plugin. configureĬC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto". RANLIB="ar -s -plugin=/path/to/llvm/lib/LLVMgold.so" CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto". I'm currently configuring CPython as follows: FilesĬPython fails to build with LLVM's link-time optimization (LTO) in Mac OS. Sjlver, brett.cannon, koobs, ned.deily, python-dev, ronaldoussoren, vstinnerĬreated on 12:11 by Sjlver, last changed 14:58 by admin. CPython fails to build modules with LLVM LTO on Mac OS X
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |