search for: polyhedron

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

Anton, I didn't have to time to do fresh set of benchmarks for llvm-gfortran from 2.4 and current gcc trunk. I'll do that this weekend. However I suspect I'll see similar behavior as before. Compared to FSF gcc 4.2, llvm-gfortran will show improvements but it won't be as impressive compared to gcc trunk. Is there a projected date for supporting the vectorization in llvm for the

FYI, I can confirm that the llvm/llvm-gcc4.2 2.5 release currently builds the Polyhedron 2005 benchmarks on i686-apple-darwin9 and the resulting code executes without errors. Nice. Jack

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 % --------- ------- ---------- ------- ------- ------ ac 1.16 10000 18.30 10...

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

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 http://llvm.org/bugs/show_bug.cgi?id=15980 >> which results in unresolved symbols fo...

I've benchmarked the llvm 2.3/llvm-gcc-4.2 release against the stock gfortran compiler from gcc 4.2.4 on a 2.33GHz MacBook Pro using the '-ffast-math -funroll-loops -msse3 -O3' optimization flags. llvm-gfortran Benchmark Compile Executable Ave Run Number Estim Name (secs) (bytes) (secs) Repeats Err % --------- ------- ---------- ------- -------

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 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 in analyzing the performance. I don't think that anyone has done *any* ll...

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 -O3 %n.f90 -o %n Be...

Peter, FYI, I am interested in dragon-egg because I have been preparing updated llvm/llvm-gcc42 2.7 packaging for fink and was considering adding in an addition dragon-egg package if the additional gcc patch didn't destablize gcc45. Also I am really interested in checking the Polyhedron 2005 benchmarks for gcc 4.5.0 with and without dragon-egg. The Polyhedron 2005 benchmarks improved about 14% on llvm-gfortran over the past 13 months without the llvm developers even targeting those. With a modern gfortran and decent vectorization support, the benchmarks could be quite interesting...

...; 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 isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don&...

...PM +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 testing. There is a small improvement in the dragonegg results (without -fplugin-arg-dragonegg-enable-gcc-optzns) in RC3. I assume we still only have partial coverage of all of the -ffast-math optimizations performed by FSF gcc in llvm's fa...

...Jack Howarth wrote: > 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 isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think tha...

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, 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 isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don't think that anyone ha...

...t;> 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 isn't bad. I imagine that there are several easy wins you could get on it if you were interested in analyzing the performance. I don'...

I am finding with the patch that all of the Polyhedron 2005 benchmarks pass on i686-apple-darwin9. Could someone clarify the regression rules for releases? Not building a secondary language on a primary target is usually considered a P1 regression for FSF gcc. Not doing so here gives one the impression that llvm.org isn't playing by the same rules....

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

...m doing, besides C and C++, it would be great to > have a Fortran frontend. Would it be very hard to compile the llvm-gcc > with suport for fortran? There is (still experimental though) support for fortran and ada frontends mostly on x86/linux. You can even find some numbers from running SPEC/polyhedron testsuites on llvm-gfortran. They are also mentioned in release notes maybe for 2-3 past releases already. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University