similar to: [LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?

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/

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 -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin \

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 \ >

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.

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'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

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

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

Hi Jack, > Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn > on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. thanks for the numbers. How does this compare to LLVM 3.0 - were there any regressions? Ciao, Duncan. The benchmarks > for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate > since

Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. The benchmarks for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate since there seems to be a bug in -msse4 on 2.33 GHz (T7600) Intel Core 2 Duo Merom (http://llvm.org/bugs/show_bug.cgi?id=12434).

Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. The benchmarks for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate since there seems to be a bug in -msse4 on 2.33 GHz (T7600) Intel Core 2 Duo Merom (http://llvm.org/bugs/show_bug.cgi?id=12434). I've added two

On 01/14/2016 02:23 AM, Ulrich Windl wrote: >> """ >> ./test-driver: line 107: 25185 Illegal instruction "$@" > $log_file > 2>&1 >> FAIL: celt/tests/test_unit_mathops >> """ > > The shell script most likely does not have the illegal instruction; a more > useful report would be to run the thing under a

On Tue, 3 Apr 2012 08:57:51 -0400 Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > > Hi Jack, > > > >> Attached are the Polyhedron 2005 benchmark results for current > >> llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode > >> 4.3.2 and FSF gcc 4.6.3. > > >

On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > Hi Jack, > >> Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn >> on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. > > thanks for the numbers. How does this compare to LLVM 3.0 - were there any > regressions? The results from just before

The Polyhedron 2005 benchmark results for dragonegg svn at r141492 using FSF gcc 4.6.2svn measured on x86_64-apple-darwin11 are listed below. The benchmarks used the optimizaton flags... -msse4 -ffast-math -funroll-loops -O3 in all cases. The use of -fplugin-arg-dragonegg-enable-gcc-optzns to allow for autovectorization from the FSF gcc front-end only produces a single run-time regression,

On Tue, Apr 03, 2012 at 08:33:33AM -0500, Hal Finkel wrote: > On Tue, 3 Apr 2012 08:57:51 -0400 > Jack Howarth <howarth at bromo.med.uc.edu> wrote: > > > On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > > > Hi Jack, > > > > > >> Attached are the Polyhedron 2005 benchmark results for current > > >> llvm/dragonegg svn

Hi Jack, > The Polyhedron 2005 benchmark results for dragonegg svn at r141492 > using FSF gcc 4.6.2svn measured on x86_64-apple-darwin11 are listed below. > The benchmarks used the optimizaton flags... > > -msse4 -ffast-math -funroll-loops -O3 > > in all cases. The use of -fplugin-arg-dragonegg-enable-gcc-optzns to allow > for autovectorization from the FSF gcc

Hi Chris, >> PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at >> the following levels: >> >> Command line option LLVM optimizers run at >> ------------------- ---------------------- >> -O1 tiny amount of optimization >> -O2 or -O3 -O1 >> -O4 or -O5