similar to: [LLVMdev] Polyhedron 2005 results for dragonegg 3.3svn

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

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

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

Jack, Can you please file a bug report and attach the BC files for the major loops that we miss ? Thanks, Nadav On Jun 2, 2013, at 1:27, Duncan Sands <duncan.sands at gmail.com> wrote: > Hi Jack, thanks for splitting out what the effects of LLVM's / GCC's vectorizers > is. > > On 01/06/13 21:34, Jack Howarth wrote: >> On Sat, Jun 01, 2013 at 06:45:48AM +0200,

Actually this kind of opportunities, as outlined bellow, was one of my contrived motivating example for fast-math. But last year we don't see such opportunities in real applications we care about. t1 = x1/y ... t2 = x2/y. I think it is better to be taken care by GVN/PRE -- blindly convert x/y => x *1/y is not necessarily beneficial. Or maybe we can blindly perform such

On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > > Duncan, > > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic > > to work around without some

Hi Jack, thanks for splitting out what the effects of LLVM's / GCC's vectorizers is. On 01/06/13 21:34, Jack Howarth wrote: > 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

Hi Jack, On 09/05/13 18:21, Jack Howarth wrote: > On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: >> On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: >>> Duncan, >>> I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn >>> for the llvm 3.3 release? Is the deprecation and poisoning of

On Thu, May 09, 2013 at 12:21:30PM -0400, Jack Howarth wrote: > On Wed, May 08, 2013 at 06:53:05AM -0700, Peter Collingbourne wrote: > > On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > > > Duncan, > > > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > > > for the llvm 3.3 release? Is the deprecation and

Hi Jack, thanks for these numbers. > With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, > the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what > were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) >

Duncan, With the commit from http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/158488.html, the Polyhedron 2005 benchmarks complete again on x86_64-apple-darwin12. The result are similar to what were seen with FSF gcc 4.6.2svn and llvm/dragonegg 3.0 (which was the last release that passed pb05) http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044091.html. Jack

Below are the results for the Polyhedron 2005 benchmarks compiled with the llvm/compiler-rt/dragonegg 3.3 release and 3.4svn against FSF gcc 4.8.2. The *-stock-de runs omit the -fplugin-arg-dragonegg-enable-gcc-optzns flag and the *-de-optnz runs include it. There seems to be little improvement between llvm 3.3 and 3.4 in the stock case which relies entirely on llvm for vectorization. Duncan, has

Comparing the Polyhedron 2005 benchmark results for gfortran from llvm-gcc-4.2 of April 7th, 2010 and September 18th, 2010 (from the rc2 2.8 release branch), we seem to be regressing in performance for this release.... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command :

On Wed, May 08, 2013 at 09:25:55AM -0400, Jack Howarth wrote: > Duncan, > I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn > for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic > to work around without some additional substitute being added in FSF gcc upstream? Hi Jack, There's a patch under review to

Duncan, I was wondering if you plan on supporting the build of dragonegg under gcc 4.8.1svn for the llvm 3.3 release? Is the deprecation and poisoning of IDENT_ASM_OP too problematic to work around without some additional substitute being added in FSF gcc upstream? Jack

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

The previously posted benchnarks for gcc vs llvm-gfortran had one mistake. I was actually had the gfortran for 4.3.1 installed instead of that from gcc 4.2.4. Below are the polyhedron benchmark results for all three compilers... gfortran 4.2.4 Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- -------

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)