search for: pb05

...mmit 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 > ps Has an exhaustive effort been made yet to insure that llvm/dragonegg isn't still unnecessarily scalarizing > the vector code generated by FSF gcc? As far as I know, no effort has been made...

Hi Jack >               dragonegg degg+vectorize degg+optnz  gfortran > ac               12.45       12.45         8.85       8.80 > gas_dyn          11.72       11.80         4.47       4.26 > induct           24.02       24.91        12.08      13.65 > rnflow           32.25       32.35        26.47      24.06 Any idea what might cause such differences here? -- With best

Hi Anton, >> dragonegg degg+vectorize degg+optnz gfortran >> ac 12.45 12.45 8.85 8.80 >> gas_dyn 11.72 11.80 4.47 4.26 >> induct 24.02 24.91 12.08 13.65 >> rnflow 32.25 32.35 26.47 24.06 > Any idea what might cause such differences

Hi Jack, > Duncan, any idea how to work around that for passing -bb-vectorize-req-chain-depth=3? it is being rejected by GCC's plugin options parser. I just implemented a hack in dragonegg in which colons will be morphed into equals signs. So you should now be able to pass -bb-vectorize-req-chain-depth:3 and have it work. Ciao, Duncan.

Hi Jack, > It would also be nice if -fplugin-arg-dragonegg-llvm-option= could allow multiple > entries surrounded by quotes. Yesterday when I tested... I implemented this: options passed this way are now split on spaces. Ciao, Duncan.

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

...ith 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 ps Has an exhaustive effort been made yet to insure that llvm/dragonegg isn't still unnecessarily scalarizing the vector code generated by FSF gcc? If that issue were completely solved, llvm/dragonegg might bec...

With current dragonegg svn, the Polyhedron 2005 benchmarks all now pass when using the compiler plugin under FSF gcc 4.6.1 on x86_64-apple-darwin11. The differences between the runtime and compile times when using the same plugin under FSF gcc 4.5.4svn are small. Once new vector_select feature is available in llvm and -fplugin-arg-dragonegg-enable-gcc-optzns supports -ftree-vectorizer we might see

On Wed, Apr 04, 2012 at 05:00:05PM +0200, Duncan Sands wrote: > Hi Jack, > >> Duncan, any idea how to work around that for passing -bb-vectorize-req-chain-depth=3? > > it is being rejected by GCC's plugin options parser. I just implemented a hack > in dragonegg in which colons will be morphed into equals signs. So you should > now be able to pass

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. The benchmarks for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate since there seems to be a bug in -msse4 on 2.33 GHz (T7600) Intel Core 2 Duo Merom (http://llvm.org/bugs/show_bug.cgi?id=12434). I've added two

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. thanks for the numbers. How does this compare to LLVM 3.0 - were there any regressions? Ciao, Duncan. The benchmarks > for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate > since

On Tue, Apr 03, 2012 at 08:33:33AM -0500, Hal Finkel wrote: > 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

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. The benchmarks for -msse3 and -msse4 appear identical (at least for degg+optnz). This is fortunate since there seems to be a bug in -msse4 on 2.33 GHz (T7600) Intel Core 2 Duo Merom (http://llvm.org/bugs/show_bug.cgi?id=12434).

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

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. > > thanks for the numbers. How does this compare to LLVM 3.0 - were there any > regressions? The results from just before

...appears that with -fplugin-arg-dragonegg-llvm-ir-optimize=2, the addition of -fplugin-arg-dragonegg-enable-gcc-optzns slows compilation by 24% with -O3 -ffast-math (which is very close to the 23% increase in compile time seen without -fplugin-arg-dragonegg-llvm-ir-optimize=2). We should rebenchmark pb05 with -O2 -ffast-math to see if -fplugin-arg-dragonegg-enable-gcc-optzns has the same impact on compile times. IMHO, if -fplugin-arg-dragonegg-enable-gcc-optzns has less effect at -O2, it would might make sense to default -fplugin-arg-dragonegg-enable-gcc-optzns on in dragonegg. That is, if the comp...

I just noticed this - I can't promise any particular amount of TLC, but I'll certainly be giving the Fortran front-end some attention as soon as LLVM moves to gcc 4.2. For future reference, does anyone know of a good free Fortran compiler test suite? Cheers, -mike On 5/14/07, Duncan Sands <baldrick at free.fr> wrote: > Hi Duraid, > > > Does anyone know what the

...1.75 1.70 1.24 test_fpu 1.38 1.41 1.05 tfft 0.31 0.28 0.19 mean 3.13 2.64 2.02 I wouldn't put a lot of faith in the compile time measurements because unlike the actual benchmark runs, pb05 doesn't attempt to repeat the compilations until it has converged on a low error measurement for the compilation time. Jack > >> >> Compile time (seconds) >> >> Benchmark A) stock B) gcc 4.5.4/ C) gcc 4.5.4/ >> gcc 4.5.4...

...-O2 > does seem to consistently result in slightly better code, so I've been thinking > of using -O2 instead. This is one reason I encouraged Jack to use -O4 in his > benchmarks (i.e. GCC at -O3, LLVM at -O2) - to see if they show the same thing. Duncan, My preliminary runs of the pb05 benchmarks at -O4, -O5 and -O6 using -fplugin-arg-dragonegg-enable-gcc-optzns didn't show any significant run time performance changes compared to -fplugin-arg-dragonegg-enable-gcc-optzns -O3. I'll rerun those and post the tabulated results this weekend. I am using -ffast-math -funroll-loo...

Hi Chris, >> PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at >> the following levels: >> >> Command line option LLVM optimizers run at >> ------------------- ---------------------- >> -O1 tiny amount of optimization >> -O2 or -O3 -O1 >> -O4 or -O5