similar to: [LLVMdev] -O4 -fvisibility=hidden

Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > After trying the recommended use of -O4 -fvisibility=hidden to > compile xplor-nih with full LTO optimizations, I discovered three > symbols become undefined... > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ > \ > -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/ > bin.Darwin_9_x86/ -lfft -lintVar

On Sun, Jan 25, 2009 at 11:38:48AM +0100, Jean-Daniel Dupas wrote: > > Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > > > After trying the recommended use of -O4 -fvisibility=hidden to > > compile xplor-nih with full LTO optimizations, I discovered three > > symbols become undefined... > > > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ >

What exactly are the current limitations for using -O4 to create shared libraries with llvm/llvm-gcc-4.2 2.5? I tried a build of xplor-nih at -O4 with llvm-gcc, llvm-g++ and llvm-gfortran. The build fails to link shared libraries with errors such as... Building xplor-nih for platform: Darwin_9_x86 [ -d /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ ] || mkdir

I'm not certain yet which commit in the last couple of days caused this, but the current llvm/dragonegg svn shows a major improvement in the runtime of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the dragonegg plugin at -O3 -ffast-math -funroll-loops. Previously the xplor-nih testsuite always executed in ~40 sec but now it is coming it at 34.5 sec which is about the

Is the new EH scheme completely compatible with the existing linker in Xcode 4.1? I am finding that today's changes break the ability to link xplor-nih with dragonegg under FSF gcc 4.6.2... de-g++46 -c thread.cc -O3 -ffast-math -funroll-loops -g -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/vmd/

Seems very likely to be related to Andy's SCEV-unroll-loops changes. --Owen On Sep 6, 2011, at 11:56 AM, Jack Howarth wrote: > I'm not certain yet which commit in the last couple of days caused this, > but the current llvm/dragonegg svn shows a major improvement in the runtime > of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the > dragonegg plugin

Try -mllvm -disable-unroll-scev if you're curious. There can be some luck involved. If you have the bitcode for the important function, I may be able to convert it into a test case to avoid regressing. I usually grab the unoptimized bitcode as follows: -emit-llvm -mllvm -disable-llvm-optzns -o module.bc -Andy On Sep 6, 2011, at 12:03 PM, Owen Anderson wrote: > Seems very likely to be

Chris, Thanks for the hint. Moving over the libLTO.dylib from llvm 2.5 solved all of the linkage errors. I was able to completely build xplor-nih at -O4 now. The core xplor and xplor-tcl testsuite show no regressions. I do get 7 testcases in the xplor-python testsuite failing with bus errors now. The xplor-tcl and xplor-python tests are all run by tcl and python respectively loading their

I am happy to report that current llvm/llvm-gcc-4.2 svn builds all of xplor-nih (a complex mix of c, c++ and fortran) with -O3 -fPIC -msse4 -ffast-math. A single fortran file exposes PR3376 which is triggered by -O3 -ffinite-math-only. The resulting build of xplor-nih completely passes its testsuite and compares very well to the same build against gcc trunk for gcc 4.4 in terms of execution time.

I was quite surprised to find that dragonegg svn can now compile all of xplor-nih (which is a complex mix of c, c++ and fortran that is a regression magnet for FSF gcc). The xplor-nih package was compiled at -O3 -ffast-math -funroll-loops for all three compilers. The xplor testsuite passed without regressions and benchmarked as follows... dragonegg svn with llvm 2.9 and FSF gcc 4.5.3svn Total