Marcus G. Daniels
2011-Apr-09 14:56 UTC
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
On 4/9/2011 6:09 AM, Duncan Sands wrote:> 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.Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to match GCC performance where GCC was faster? Marcus
On Sat, Apr 09, 2011 at 08:56:49AM -0600, Marcus G. Daniels wrote:> On 4/9/2011 6:09 AM, Duncan Sands wrote: > > 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. > Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to > match GCC performance where GCC was faster?Marcus, Dragonegg 2.9 doesn't appear to be compatible with that flag at -O3. I see compilation failures of the form... /sw/lib/gcc4.5/bin/gfortran -O3 -fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -fplugin-arg-dragonegg-enable-gcc-optzns ac.f90 -o ac <misaligned_indirect_ref 0x1438ad230 type <vector_type 0x141d6ad20 type <real_type 0x141d1e0a8 real(kind=8) DF size <integer_cst 0x141d01a50 constant 64> unit size <integer_cst 0x141d01a78 constant 8> align 64 symtab 0 alias set 2 canonical type 0x141d1e0a8 precision 64 pointer_to_this <pointer_type 0x141d1e2a0> reference_to_this <reference_type 0x141e720a8>> V2DF size <integer_cst 0x141d01c58 constant 128> unit size <integer_cst 0x141d01c80 constant 16> align 128 symtab 0 alias set 2 canonical type 0x141d6ad20 nunits 2 pointer_to_this <pointer_type 0x141d74930>> arg 0 <ssa_name 0x143846580 type <pointer_type 0x141d74930 type <vector_type 0x141d6ad20> public unsigned DI size <integer_cst 0x141d01a50 64> unit size <integer_cst 0x141d01a78 8> align 64 symtab 0 alias set -1 canonical type 0x141d74930> var <var_decl 0x143845460 vect_pdsauto.757>def_stmt vect_pdsauto.757_3065 = vect_pdsauto.832_3197 + 8; version 3065> arg 1 <integer_cst 0x141dea4d8 type <integer_type 0x141d11000> constant 64>> Not a gimple constant! UNREACHABLE executed at /sw/src/fink.build/dragonegg-gcc45-2.9-1/dragonegg-2.9/Convert.cpp:5904! *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_FINISH_UNIT | dragonegg PLUGIN_FINISH | dragonegg PLUGIN_START_UNIT | dragonegg ac.f90: In function ‘MAIN__’: ac.f90:109:0: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This appears to be due to the -ftree-vectorize as -O3 --fno-tree-vectorize doesn't show this ICE but -O2 -ftree-vectorize does. Jack> > Marcus > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Marcus G. Daniels
2011-Apr-09 16:53 UTC
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
On 4/9/2011 10:28 AM, Jack Howarth wrote:> This appears to be due to the -ftree-vectorize as -O3 --fno-tree-vectorize doesn't show this ICE but -O2 -ftree-vectorize does.Is -ftree-vectorize crucial to performance in these Polyhedral benchmarks? (I've seen -fplugin-arg-dragonegg-enable-gcc-optzns make a factor of 2 improvement in execution time.) Marcus
Hi Jack,> Dragonegg 2.9 doesn't appear to be compatible with that flag at -O3. I see > compilation failures of the form......> This appears to be due to the -ftree-vectorize as -O3 --fno-tree-vectorize doesn't show this ICE but -O2 -ftree-vectorize does.the -fplugin-arg-dragonegg-enable-gcc-optzns is indeed not very stable due to the GCC optimizers producing stuff that you don't get directly from front-ends. Not to mention that I didn't spend much time working on it. Ciao, Duncan.
Possibly Parallel Threads
- [LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
- [LLVMdev] Fwd: help with llvm-convert
- [LLVMdev] Failure to compile llvm-gcc-4.2-2.7 on FreeBSD on sparc machine
- [LLVMdev] llvm-2.4 prerelease gfortran results
- [LLVMdev] Re: Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM