similar to: [LLVMdev] bdver1 cpu(bulldozer) support with dragonegg

On 30.11.2011, at 08:33, Duncan Sands wrote: > Hi Jan, > >> if I compile with dragonegg and -march=native I get this message: >> 'bdver1' is not a recognized processor for this target (ignoring processor) > > this is coming directly from LLVM which doesn't know about bulldozer yet. > >> Is there any plan to support this cpu ? > > I don't

Hi Jan, > if I compile with dragonegg and -march=native I get this message: > 'bdver1' is not a recognized processor for this target (ignoring processor) this is coming directly from LLVM which doesn't know about bulldozer yet. > Is there any plan to support this cpu ? I don't know. Hopefully someone who knows something about this will comment. Ciao, Duncan. >

Benjamin Kramer <benny.kra at googlemail.com> writes: > On 30.11.2011, at 08:33, Duncan Sands wrote: > >> Hi Jan, >> >>> if I compile with dragonegg and -march=native I get this message: >>> 'bdver1' is not a recognized processor for this target (ignoring processor) >> >> this is coming directly from LLVM which doesn't know about

Better be quick! I am adding FMA4 and XOP now, and if you contribute code before I do, you can spare yourself some XOP merging. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Benjamin Kramer <benny.kra at googlemail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 1, 2011 12:19 PM > Subject: Re: [LLVMdev]

Jan Sjodin <jan_sjodin at yahoo.com> writes: > Better be quick! I am adding FMA4 and XOP now, and if you contribute > code before I do, you can spare yourself some XOP merging. Go ahead. We're not going to get there soon enough. :( -Dave

That is too bad. :(  You can always review the patches, and if you see something that can be done better let me know. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Jan Sjodin <jan_sjodin at yahoo.com> > Cc: David A. Greene <greened at obbligato.org>; Benjamin Kramer <benny.kra at googlemail.com>; "llvmdev at

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 gcc 4.5.3svn using the himenoBMTxpa benchmark, the enhancement to code performance from

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

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 gcc 4.5.3svn using the himenoBMTxpa benchmark, > the enhancement to code performance from

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:

Current dragonegg svn has all of the -fplugin-arg-dragonegg-enable-gcc-optzns bugs for usage with -ffast-math -O3 addressed except for those related to PR2314. Using the -fno-tree-vectorize option, we can evaluate the current state of -fplugin-arg-dragonegg-enable-gcc-optzns with the Polyhedron 2005 benchmarks compared to stock dragonegg and stock gcc 4.5.4. The runtime benchmarks below show that

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

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

hi, I have dragonegg r131864, gcc-4.5 r174052 and llvm r131897. When i tried to make the llvm test-suite, i got a error message: /home/ether/local/gcc-4.5/bin/gcc -fplugin=/home/ether/sources/dragonegg/dragonegg.so -I/home/ether/build/llvm-ts/projects/test-suite/SingleSource/UnitTests/Vector/SSE -I/home/ether/sources/llvm/projects/test-suite/SingleSource/UnitTests/Vector/SSE

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:

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

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)

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

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

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