similar to: [LLVMdev] LLVM Profiler uses 32-bit counters for Basic Blocks?

On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: > Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, > so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great > if you could redo the benchmarks rc3. > Duncan, As requested, appended are the updated Polyhedron 2005 benchmark results with both RC1 and RC3 llvm 3.3

On Thu, Jun 09, 2011 at 08:47:26PM -0400, Jack Howarth wrote: > Duncan, > Here are the complete benchmarks rerun against gcc 4.5.4 built with... > > Using built-in specs. > COLLECT_GCC=gfortran-fsf-4.5 > COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper > Target: x86_64-apple-darwin11.0.0 > Configured with:

On Thu, Jun 09, 2011 at 03:44:40PM +0200, Duncan Sands wrote: > Hi Jack, thanks for doing this. > >> Below are the tabulated compile times and executable sizes. >> >> A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize >> B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns >> C)

Hi Jack, On 29/05/13 22:04, Jack Howarth wrote: > On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: >> Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, >> so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great >> if you could redo the benchmarks rc3. >> > > Duncan, > As requested, appended

Duncan, With r182593, the dragonegg 3.3 branch now completely passes the Polyhedron 2005 benchmarks using the FSF gcc 4.8.1svn compiler. Thanks. Jack Tested on x86_apple-darwin12 Compile Flags: -ffast-math -funroll-loops -O3 de-gfortran47: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -specs=/sw/lib/gcc4.7/lib/integrated-as.specs de-gfortran48:

On Fri, Apr 15, 2011 at 08:53:19AM +0200, Duncan Sands wrote: > Hi Jack, > > > Now that dragoneegg is robust in its default usage and the dragonegg svn > > is moderately stable with -fplugin-arg-dragonegg-enable-gcc-optzns, it is > > possible to gauge the impact of that feature. Comparing clang 2.9, FSF gcc 4.5.3svn, > > FSF gcc 4.6.0 and dragonegg svn with FSF

There's a hack in lib/Driver/ToolChains/Clang.cpp to accept "-mllvm -disable-llvm-optzns" as a hack for legacy compatibility. It's deprecated and the -Xclang spelling should be used. There does appear to be a bug with "-mllvm -disable-llvm-optzns" and -save-temps. -save-temps causes clang to be invoked separately to text assembly into binary code, and it looks like

On Thu, May 23, 2013 at 03:40:00PM +0200, Duncan Sands wrote: > Hi Jack, > > On 23/05/13 15:37, Jack Howarth wrote: >> Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current >> FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is

clang -O3 -mllvm -help -c LULESH.cc succeeds. On Tue, Jan 9, 2018 at 2:05 AM, toddy wang <wenwangtoddy at gmail.com> wrote: > Quick results: > > [twang15 at c89 temp]$ clang -mllvm -help > clang-5.0: error: no input files > [twang15 at c89 temp]$ clang -mllvm -help-hidden > clang-5.0: error: no input files > [twang15 at c89 temp]$ clang -mllvm --help-hidden >

Thanks for pointing this out. The following is a more extensive test. //succeed means dumping help info without Error message. clang -help #succeed 'clang -help-hidden' #Fail 'clang --help-hidden' #Succeed clang -mllvm -v -help #Succeed clang -mllvm -v -help-hidden #Fail clang -mllvm -v --help-hidden #Succeed 'clang -mllvm -help -c LULESH.cc' #Succeed 'clang -mllvm

Hi Jack, thanks for doing this. > Below are the tabulated compile times and executable sizes. > > A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize > B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns > C) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize These numbers really

On Thu, Jun 09, 2011 at 03:44:40PM +0200, Duncan Sands wrote: > Hi Jack, thanks for doing this. > >> Below are the tabulated compile times and executable sizes. >> >> A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize >> B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns >> C)

Thanks for the help. When I run the following (where $llvm is the path to my llvm installation): $llvm/bin/llvm-gcc -c -o - -O1 tmp.c -emit-llvm -mllvm --disable-llvm-optzns | $llvm/bin/opt -raiseallocs I get the following error: cc1: error: unrecognized command line option "-fdisable-llvm-optzns" I am running llvm 2.5. I performed a $llvm/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1

On Sat, Jun 01, 2013 at 06:45:48AM +0200, Duncan Sands wrote: > > These results are very disappointing, I was hoping to see a big improvement > somewhere instead of no real improvement anywhere (except for gas_dyn) or a > regression (eg: mdbx). I think LLVM now has a reasonable array of fast-math > optimizations. I will try to find time to poke at gas_dyn and induct: since >

Hi guys, According to this patch review: *Title: Remove the '-disable-llvm-passes' flag (which I didn't even know existed, and I suspect many others aren't aware of either) and strength '-disable-llvm-optzns' to do the same thing* Link: https://reviews.llvm.org/D28047 *-disable-llvm-optzns and -disable-llvm-passes are aliasing each other.* *1. Both can be passed to cc1

Duncan, Here are the complete benchmarks rerun against gcc 4.5.4 built with... Using built-in specs. COLLECT_GCC=gfortran-fsf-4.5 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper Target: x86_64-apple-darwin11.0.0 Configured with: ../gcc-4.5.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.5/info

Duncan, Below are the tabulated compile times and executable sizes. A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns C) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize Compile time (seconds) Benchmark A) stock B) gcc 4.5.4/ C)

Hi Jack, thanks for these numbers. Can you also please measure compile times? I'm thinking of enabling gcc optimizations by default, but I don't want to increase compile times, which means choosing a value for the -fplugin-arg-dragonegg-llvm-ir-optimize option that is low enough to get good compile times, yet high enough to get fast code. It would be great if you could play around with

Quick results: [twang15 at c89 temp]$ clang -mllvm -help clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm -help-hidden clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm --help-hidden clang-5.0: error: no input files [twang15 at c89 temp]$ clang -mllvm --help clang-5.0: error: no input files Anything wrong? On Tue, Jan 9, 2018 at 1:56 AM, Craig Topper

Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this