classification
Title: CPython fails to build modules with LLVM LTO on Mac OS X
Type: Stage:
Components: Build, macOS Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Sjlver, brett.cannon, koobs, ned.deily, python-dev, ronaldoussoren, vstinner
Priority: normal Keywords: patch

Created on 2014-04-01 12:11 by Sjlver, last changed 2016-09-06 23:22 by brett.cannon. This issue is now closed.

Files
File name Uploaded Description Edit
issue21122.diff brett.cannon, 2016-09-02 22:34 review
Messages (12)
msg215307 - (view) Author: Jonas Wagner (Sjlver) * Date: 2014-04-01 12:11
CPython fails to build with LLVM's link-time optimization (LTO) in Mac OS. Very similar commands work on Linux.

I'm currently configuring CPython as follows:

on Linux:
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" ./configure

on Mac OS:
CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure

The RANLIB variable should not be needed on Mac, because its toolchain does not need a GOLD plugin.

On Linux, the above builds correctly and passes most of the test suite. On Mac, I receive the following error (similar for other extensions):

building '_scproxy' extension
/usr/bin/clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -flto -I../cpython/Include -I. -I/usr/local/include -I../cpython/Include -I../cpython-lto-build -c ../cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o
/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
*** 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
  Referenced from: build/lib.macosx-10.9-x86_64-3.5/_scproxy.so
  Expected in: flat namespace
 in build/lib.macosx-10.9-x86_64-3.5/_scproxy.so
msg215311 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-04-01 13:16
What is your clang version? See also issue #20767.
msg215314 - (view) Author: Jonas Wagner (Sjlver) * Date: 2014-04-01 13:20
I am indeed using Clang 3.4 (both the one that ships with Mac OS, and a version compiled from the sources).

However, the errors I get are rather different than #20767. In particular, Clang finishes successfully and does produce shared object files; they just don't seem to be loadable.
msg215344 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-04-01 22:33
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:

 _PyArg_ParseTuple
 _PyArg_ParseTupleAndKeywords
 _PyBaseObject_Type
 _PyBool_Type
 _PyByteArray_Type
 _PyBytes_Type
 _PyCFunction_Type
 _PyExc_AssertionError
 _PyExc_BufferError
 _PyExc_EOFError
 _PyExc_IndexError
 _PyExc_IOError
 _PyExc_KeyError
 _PyExc_LookupError
 _PyExc_MemoryError
 _PyExc_NotImplementedError
 _PyExc_OSError
 _PyExc_OverflowError
 _PyExc_RuntimeError
 _PyExc_TypeError
 _PyExc_ValueError
 _PyModule_Create2
 __Py_NoneStruct

Anyone see a pattern there? 

Do 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.  Also, some thought would need to go into and tests developed to see what the performance trade-offs are.  For example, I could imagine that LTO might be have more impact if the standard library extension modules were statically linked, e.g. via Modules/Setup*.  And there are at least three separate current build configurations to consider on OS X: unshared, --enable-shared, --enable-framework.  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.  It certainly would be an interesting project for someone with the interest and time.

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.
msg215362 - (view) Author: Jonas Wagner (Sjlver) * Date: 2014-04-02 07:55
Thanks Ned, this is interesting!

I don't know about Mac OS, but on Ubuntu, LTO and PGO apparently make Python around 10% faster (see #17781). However, that data point refers to GCC's LTO, not LLVM's.

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, if there is something I can help (e.g., running benchmarks with different compilation settings), let me know.
msg215364 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2014-04-02 09:14
I've used -O4 for extensions in the past (which until recently implied LTO) and that worked fine. 

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 :-)

BTW. There's no clear pattern in the missing symbols. The missing symbols for global functions could be due to aggressive inlining (and then deciding that the standalone function isn't needed anymore), but that is fairly unlikely and wouldn't explain the missing data symbols.
msg215366 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2014-04-02 09:19
Have you tried the -export_dynamic option for ld(1):


-export_dynamic
                 Preserves all global symbols in main executables during LTO.  Without this option, Link Time Optimization is allowed to inline and remove global functions. This
                 option is used when a main executable may load a plug-in which requires certain symbols from the main executable.
msg215367 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2014-04-02 09:33
This works for me (with a separate build directory):

  CC=clang CXX=clang++ CFLAGS="-g -flto" LDFLAGS="-flto -Wl,-export_dynamic" ../configure

This is on OSX 10.9.2, with Xcode 5.1, and clang --version says:

$ clang --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

Tests are still running, but so far there are no unexpected failures.
msg215522 - (view) Author: Jonas Wagner (Sjlver) * Date: 2014-04-04 13:50
I confirm that this also works with my self-compiled Clang 3.4. -export_dynamic was the missing option.

Is a good place to document this?

Otherwise, I think this issue can be closed. Thanks a lot for the help!
msg226645 - (view) Author: Jonas Wagner (Sjlver) * Date: 2014-09-09 16:37
No response for a while, and problem solved... closing.
msg274278 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2016-09-02 22:34
Here is a patch to turn on `-Wl,-export_dynamic` when building with LTO. Unfortunately I have a bunch of tests that fail when running with LTO+PGO of the form of:

[ 95/398] test_bytes
Traceback (most recent call last):
  File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 1593, in main_in_temp_cwd
    main()
  File "/Users/brettcannon/Repositories/python/cpython/3.5/Lib/test/regrtest.py", line 756, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_bytes: Exit code -6
msg274639 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-09-06 22:10
New changeset cc5f8179a7ba by Ned Deily in branch 'default':
Issue #21122: Fix LTO builds on OS X.
https://hg.python.org/cpython/rev/cc5f8179a7ba
History
Date User Action Args
2016-09-06 23:22:25brett.cannonsetstatus: open -> closed
resolution: fixed
2016-09-06 22:10:02python-devsetnosy: + python-dev
messages: + msg274639
2016-09-02 22:34:59brett.cannonsetcomponents: + macOS
2016-09-02 22:34:46brett.cannonsetstatus: closed -> open
files: + issue21122.diff
messages: + msg274278

keywords: + patch
resolution: fixed -> (no value)
2016-09-02 21:58:08brett.cannonlinkissue26359 dependencies
2014-09-09 16:37:46Sjlversetstatus: open -> closed
resolution: fixed
messages: + msg226645
2014-04-04 13:50:46Sjlversetmessages: + msg215522
2014-04-02 09:33:14ronaldoussorensetmessages: + msg215367
2014-04-02 09:19:16ronaldoussorensetmessages: + msg215366
2014-04-02 09:14:40ronaldoussorensetmessages: + msg215364
2014-04-02 07:55:52Sjlversetmessages: + msg215362
2014-04-01 22:33:52ned.deilysettype: compile error ->
title: CPython fails to build modules with LLVM LTO on Mac OS -> CPython fails to build modules with LLVM LTO on Mac OS X
components: + Build, - Extension Modules

nosy: + brett.cannon, ronaldoussoren, ned.deily
versions: + Python 3.5, - Python 3.4
messages: + msg215344
2014-04-01 13:20:06Sjlversetmessages: + msg215314
2014-04-01 13:16:15vstinnersetmessages: + msg215311
2014-04-01 12:14:56vstinnersetnosy: + koobs
2014-04-01 12:14:50vstinnersetnosy: + vstinner
2014-04-01 12:11:00Sjlvercreate