similar to: [LLVMdev] llvm-gfortran polyhedron 2005 results

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

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 Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > Building the current release 2.7 branch on x86_64-apple-darwin10 > with r81455 reverted, I get the following Polyhedron 2005 benchmark > results (with no test failures)... Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested

On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt

Building the current release 2.7 branch on x86_64-apple-darwin10 with r81455 reverted, I get the following Polyhedron 2005 benchmark results (with no test failures)... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3

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

On Apr 8, 2010, at 8:45 AMPDT, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC.

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets

On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote: > > On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > > > Building the current release 2.7 branch on x86_64-apple-darwin10 > > with r81455 reverted, I get the following Polyhedron 2005 benchmark > > results (with no test failures)... > > Very nice! A 14% speedup on a benchmark we don't tune for

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 >

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, thanks for the numbers. Any chance of analysing why gcc does better on those where it does much better than dragonegg? Ciao, Duncan. > With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 > applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 > under gcc 4.5.3svn using the dragonegg

On Mon, Feb 21, 2011 at 03:58:19PM -0800, Eric Christopher wrote: > > On Feb 19, 2011, at 11:25 AM, Jack Howarth wrote: > > > Is anyone able to bootstrap llvm-gcc42 svn on x86_64-apple-darwin10? Currently it is > > failing here with... > > It was broken. I think I've fixed it in reverting 125960. > > -eric Eric, The llvm-gcc42 bootstrap is fixed in

With the case-insensitive file system patch from http://llvm.org/bugs/show_bug.cgi?id=9656#c15 applied to dragonegg 2.9, the following Polyhedron 2005 benchmarks are seen on x86_64-apple-darwin10 under gcc 4.5.3svn using the dragonegg plugin... ================================================================================ Date & Time : 8 Apr 2011 19:52:56 Test Name :

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

The current llvm/llvm-gcc-4.2 2.6 branch passes all of the Polyhedron 2005 benchmarks built with its gfortran. The results compare as follows... Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n benchmark gcc-4.2.4 llvm-gcc-svn llvm-gcc-2.6 llvm-gcc-2.6 at -m32 20081031 -m32 at -m32 at -m64 ac 18.30

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