similar to: [LLVMdev] DragonEgg3.3 support for gcc cross compilers

No. The gcc cross compiler being used (tilera-gcc) is indeed 64-bit. Thanks On Tue, Oct 28, 2014 at 11:01 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > Looks like your gcc is 32-bit and you're trying to load 64-bit plugin. > > On Tue, Oct 28, 2014 at 8:27 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > > Hi Brian, > > > >

Hi Brian, Thanks for sharing your experience with dragonegg. I would like to use tilera-gcc as the compiler driver. native gcc would not be able to handle things like tilera specific intrinsics in the source code. I built dragonegg using GCC=/path/to/tilera-gcc48/bin/tile-gcc LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make and also tried only emitting the IR

Hello All, Another newbie question. I am confused as to what options will work with "fplugin-arg-dragonegg-llvm-option" for dragonegg plugin. Readme says it is used to pass command-line options to llvm. I shall consolidate into 3 questions. For all examples below, I used combo- gcc 4.6 + dragonegg(trunk) + llvm(trunk) (1). Does 'fplugin-arg-dragonegg-llvm-option' allow all

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

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

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

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

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)

Duncan, 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 Compile time (seconds) Benchmark A) stock B) gcc 4.5.4/ C)

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:

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

Hello All, Another newbie question. I am confused as to what options will work with "fplugin-arg-dragonegg-llvm-option" for dragonegg plugin. Readme says it is used to pass command-line options to llvm. I shall consolidate into 3 questions. For all examples below, I used combo- gcc 4.6 + dragonegg(trunk) + llvm(trunk) (1). Does 'fplugin-arg-dragonegg-llvm-option' allow all

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

Duncan, Is the documentation for using Polly support in dragonegg correct? I built llvm/polly/dragonegg using the documentation at http://polly.llvm.org/example_load_Polly_into_dragonegg.html with... GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config ENABLE_LLVM_PLUGINS=1 make CPPFLAGS="-DENABLE_LTO -I/sw/include" The resulting dragonegg plugin works fine

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

On 11/08/2010 03:18 PM, Duncan Sands wrote: > Hi Tobias, > >> I am very interested in using dragonegg as a fortran frontend for the >> LLVM test >> suite, as a start to improve fortran support. >> >> I believe this should be easy, but when I looked into this I had the >> impression >> the nightly tester in the llvm test-suite does not even support

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

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 Shahzad, > Is it possible that we can use LLVM optimization beside O1, O2, O3 > along with dragonegg plugin? sure, try this: gcc -fplugin=path/dragonegg.so ...other_options_here... -S -o - -fplugin-arg-dragonegg-emit-ir -fplugin-arg-dragonegg-llvm-ir-optimize=0 | opt -pass1 -pass2 ... Here -fplugin-arg-dragonegg-emit-ir tells it to output LLVM IR rather than target assembler.