On Mon, Jan 26, 2009 at 09:57:28AM -0800, Devang Patel wrote:> Hi Jack, > > On Jan 25, 2009, at 10:00 AM, Jack Howarth wrote: > > > Doing that changes the error messages into a bus > > error on the darwin linker. > > > Pl. file bugzilla report (or radar) with a reproducible test case so > that we can investigate this linker crash. > > As you know, one way to control symbol visibility is to use gcc's > (inherited by llvm-gcc) visibility support. GCC supports, 1) command > line options 2) attributes and 3) pragmas in this regard. Following > document provides good summary... > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html#/ > /apple_ref/doc/uid/TP40001670 > > Another way to control symbol visibility is to use linker's interface. > See ld man page for more info on -exported_symbols_list, - > exported_symbols, -unexported_symbols_list etc.. flags. If you're > going to try this approach, pl. read ld man page first. > - > Devang > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevDevang, I was surprised to discover that I could build all of pymol with -fvisibility=hidden using gcc 4.4 or llvm-gcc-4.2 with only a single header change... --- pymol-1.1/layer4/Cmd.h.orig 2009-01-30 18:58:58.000000000 -0500 +++ pymol-1.1/layer4/Cmd.h 2009-01-30 19:00:17.000000000 -0500 @@ -18,7 +18,8 @@ #include"os_python.h" -void init_cmd(void); +void init_cmd(void) +__attribute__((visibility("default"))); extern PyObject *PM_Globals; One of the advantages of running as a python module I guess. I was also able to build pymol with -O4 using the llvm 2.5 libLTO.dylib so that full Link Time Optimizations were performed. Everything compiled and linked fine. The resulting pymol runs its demos without regressions. Nice. Jack
I was able to also build sparky (http://www.cgl.ucsf.edu/home/sparky/)
at -O4 under llvm-gcc-4.2 and llvm-g++-4.2 on darwin with minor patches...
--- sparky/c++/_tkinter.c.orig 2009-01-30 22:14:28.000000000 -0500
+++ sparky/c++/_tkinter.c 2009-01-30 22:16:40.000000000 -0500
@@ -3089,6 +3089,9 @@
}
}
+PyMODINIT_FUNC
+init_tkinter(void)
+__attribute__((visibility("default")));
PyMODINIT_FUNC
init_tkinter(void)
--- sparky/c++/python.cc.orig 2009-01-30 22:23:07.000000000 -0500
+++ sparky/c++/python.cc 2009-01-30 22:23:36.000000000 -0500
@@ -3566,6 +3566,9 @@
// Initialization routine called by python when module is dynamically loaded.
//
extern "C" void initspy()
+__attribute__((visibility("default")));
+
+extern "C" void initspy()
{
this_module = Py_InitModule("spy", sparky_methods);
Py_XINCREF(this_module);
Tk/Python driven software appears very friendly to -fvisibility=hidden.
Are there any particular optimization options that one should use besides
-O4 -fvisibility=hidden to enable all of the possible llvm Link Time
Optimizations?
Also, I assume that one only needs to compile the object files with
-O4 -fvisibility=hidden and that the actual linkage doesn't need those
flags to enable full LTO, correct? FYI, sparky builds with no errors and
no regressions with -O4 -fvisibility=hidden.
Jack
On Jan 30, 2009, at 7:42 PM, Jack Howarth wrote:> Tk/Python driven software appears very friendly to - > fvisibility=hidden.Nice!> Are there any particular optimization options that one should use > besides > -O4 -fvisibility=hidden to enable all of the possible llvm Link Time > Optimizations?Nope, that should be enough. "-O4" is effectively -O3 + -flto. You might also try -O2 -flto explicitly if you care about code size.> Also, I assume that one only needs to compile the object files with > -O4 -fvisibility=hidden and that the actual linkage doesn't need those > flags to enable full LTO, correct?Right. Is there a significant code size or perf difference with lto? -Chris