[autovect] autovect-branch reopened from latest trunk
I've reopened a new branch autovect-branch, taken off the trunk as of today. The branchpoint revision is 120362. The old branch went way out of synch with mainline so I've moved it to branches/dead/old-autovect-branch in svn repository. New autovect-branch has initialized merge tracking support for svnmerge.py tool to facilitate merges from trunk in future. -- Victor
Re: Scheduling an early complete loop unrolling pass?
Richard Guenther <[EMAIL PROTECTED]> wrote on 06.02.2007 11:19:15: > On Tue, 6 Feb 2007, Dorit Nuzman wrote: > > After sleeping on it, it actually makes a lot of sense to me to schedule > > complete loop unrolling before vectorization - I think it would either > > simplify loops (sometimes creating more opportunities for vectorization), > > or prevent vectorization of loops we probably don't want to vectorize > > anyhow, and even that - only temporarily - until we have straight-line-code > > vectorization in place. So I'm all for it. > > Ok, I'll dig out the patches I had for this and will do some SPEC > runs. As soon as I have time for this (no hurry necessary here I think). We have some benchmarks where complete unrolling of innermost loop expose an opportunity to vectorize an outer loop. Usually complete unrolling reveal some opportunities for constant propagation and dead code elimination, so, probably there is need to rerun ccp, store_cpp, dse and dce between complete unrolling and vectorizer. I would be glad to help with running of SPEC on PPC. -- Victor
Re: Fw: Cross Compiler to Native Compiler
Just use your cross-compiler to build a compiler for the target system that'll run on the target system. Then it could be good idea to use new native compiler on its hardware to rebuild gcc once again natively. Two compilers from last two steps should be identical. It's a good way to make sure your cross and native compilers are working correctly, and generating code that actually runs. Have a look at how canadian cross compiler are built, that might give you a hint. Some hacking the script for building canadian cross-compiler may help (See CrossGCC FAQ for details - http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/). But be sure to edit specs and change cross_compile to 0 later as specs are dumped by cross-compiler. you can find some more info in this thread: http://sourceware.org/ml/crossgcc/2005-02/msg5.html -- Victor > > Cross Compiler to Native Compiler > > Hi, > > I am porting/developing GCC onto a new platform. > This platform already have a cross tool chain. > Can anybody give me a roadmap to port GCC in native > environment from scratch? or > Way to convert, Croos-Compiler to Native-Compiler? > > Thanks n Regards, > Kapil
Re: Problem with building libgfortran on PPC
I have obtained the same error on my ppc64 yellow dog linux: /bin/sh ./libtool --mode=compile /home/victork/mainline-vanila/build/./gcc/gfortran -B/home/victork/mainline-vanila/build/./gcc/ -B/home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/bin/ -B/home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/lib/ -isystem /home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/include -isystem /home/victork/mainline-vanila/usr/ppc64-yellowdog-linux/sys-include -m64 -fPIC -mstrict-align -DHAVE_CONFIG_H -I. -I../../../../gcc/libgfortran -I. -iquote../../../../gcc/libgfortran/io -I../../../../gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -m64 -fPIC -mstrict-align -c -o _sign_r10.lo `test -f '../../../../gcc/libgfortran/generated/_sign_r10.F90' || echo '../../../../gcc/libgfortran/'`../../../../gcc/libgfortran/generated/_sign_r10.F90 collect2: ld terminated with signal 11 [Segmentation fault] make[8]: *** [libstdc++.la] Error 1 make[8]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3/src' make[7]: *** [all-recursive] Error 1 make[7]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3' make[6]: *** [all] Error 2 make[6]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/64/libstdc++-v3' make[5]: *** [multi-do] Error 1 make[5]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[4]: *** [all-multi] Error 2 make[4]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/victork/mainline-vanila/build/ppc64-yellowdog-linux/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 % uname -a Linux mac-victork.haifa.ibm.com 2.6.10-1.yhpc.1smp #1 SMP Thu Mar 17 19:38:06 MST 2005 ppc64 ppc64 ppc64 GNU/Linux svn main trunk revision = 123035 configuration: ../gcc/configure \ --prefix=/home/victork/mainline-vanila/usr \ --enable-shared \ --enable-threads=posix \ --with-system-zlib \ --enable-__cxa_atexit \ --enable-symvers=gnu \ --host=ppc64-yellowdog-linux \ --build=ppc64-yellowdog-linux \ --target=ppc64-yellowdog-linux \ --with-cpu=default32 \ --enable-biarch \ --enable-languages=c,c++,fortran -- Victor > I get the following error on PPC while bootstrapping mainline. > Re-runing make I get: > collect2: ld terminated with signal 11 [Segmentation fault] > make[8]: *** [libstdc++.la] Error 1 > Thanks, > Revital
Re: GCC 4.2 Status Report (2006-04-19)
[EMAIL PROTECTED] wrote on 20-04-2006 12:47:54 AM: > > 3) autovectorization improvements > > Good autovectorization is becoming ever more-important in performance > evaluation. Is there someone who can review this patch? > > Are there other things that are approximately ready for inclusion that > we should try to get into 4.2? We have submitted for mainline 4.2 two patches for review. Still waiting for approvement: 1. Vectorize type conversions: support vectorization in the presence of data-types of different sizes. part1 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00940.html (cleanup) part2 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00941.html (multiple-types for loads/stores) part3 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00942.html (multiple-types for simple operations) part4 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00943.html (multiple-types for reduction) part5 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg00944.html (type demotion) part6 - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg01453.html (type promotion) entire patch - http://gcc.gnu.org/ml//gcc-patches/2006-02/msg01454.html 2. Interleaved memory access: support vectorization in the presence of strided loads in the loop. http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html Additionaly we are working on tree-vectorize and tree-ifcvt enhancements to enable vectorization of EEMBC telecom/vitervi benchmark. This is expected to be ready at early May/2006. Should we consider this for 4.2 too? thanks, -- Victor
Re: Memory leaks in compiler
> When a loop is vectorized, some statements are removed from the basic > blocks, but the vectorizer information attached to these BBs is never > freed. This is because the attached information is freed by walking > the statements of the basic blocks: see tree-vectorizer.c:1750, but > the transformed code does not contain all the stmts of the original > code. I can't find out a good solution for tracking these stmts, but > one solution could be to free the stmt_info when the stmts are removed > from a BB. Sebastian, thanks for bringing this to our attention. I'll look into this. I hope that removing stmts from a BB can be easily localized. -- Victor
