Re: svn tag inspection
On Sat, 2005-10-22 at 03:25 +0200, Giovanni Bajo wrote: > Besides the fact that you must have used -N, remember that you don't need all > those merging tags anymore (forever). You can either live with a single tag > per > branch which you move along, or don't use tags alone and use svnmerge.py (see > contrib scripts in 1.3). I am going to write some details in the wiki about > this (I wrote svnmerge.py). > > In fact, after the subversion conversion is over, we can "svn delete" all > those > merging tags for good since they're there because you can't delete them in CVS > but we really don't need them anymore (before anybody asks: "svn delete" keeps > history of course). Just a minor correction, you can certainly delete cvs tags. It just isn't something I'd necessarily recommend doing :-) cvs tag -d Jeff
Vectorizing HIRLAM II: Using the autovect branch compiler.
L.S., Using the autovect branch compiler: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/vec --disable-nls --disable-multilib --enable-languages=f95 Thread model: posix gcc version 4.1.0 20051022 (experimental) I now get the following results: Number of potentially vectorizable loops:9799. Number of loops vectorized: 2658. Number of loops not vectorized: 7141. Of which: - due to unhandled data-refs: 3078. - due to complicated access patterns: 1573. - due to undeterminable dependence:1224. - due to unsupported use in statement: 674. - due to no vectype in statement (complex8):238. So this version of the compiler performs slightly better. The reduction in the number of potentially vectorizable loops is due to me rsync'ing a new version of HIRLAM where various duplicated libraries have been merged. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 1: This dependence is determinable.
This one does get vectorized with autovect-branch: [ example with source and destination array exactly overlapping ] ~/autovect_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=4 -S hilaram1.f90 hilaram1.f90:5: note: dependence distance = 0. hilaram1.f90:5: note: accesses have the same alignment. hilaram1.f90:5: note: dependence distance modulo vf == 0 between (*a_25)[D.949_60] and (*a_25)[D.949_60] hilaram1.f90:5: note: Alignment of access forced using peeling. hilaram1.f90:5: note: Vectorizing an unaligned access. hilaram1.f90:5: note: LOOP VECTORIZED. hilaram1.f90:9: note: vectorized 1 loops in function. dorit Indeed, it works on x86_64-unknown-linux-gnu too, with the autovect branch. > L.S., > > This code: > > SUBROUTINE S(N, M) > DIMENSION A(N, M), B(N, M) > READ*,A,B > DO J = 1, M > DO I = 1, N > A(I, J) = A(I, J) + B(I, J) > ENDDO > ENDDO > PRINT*,A > END Unfortunately, it's only this example that works. I still see a lot of cases when using the autovect branch compiler on HIRLAM. I'll try to distill another example. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
This one gets vectorized for me, on powerpc-linux:
~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
-ftree-vectorizer-verbose=4 -S hilaram4.f90
hilaram4.f90:4: note: Alignment of access forced using peeling.
hilaram4.f90:4: note: Vectorizing an unaligned access.
hilaram4.f90:4: note: LOOP VECTORIZED.
hilaram4.f90:7: note: vectorized 1 loops in function.
dorit
> L.S.,
>
> This code:
>
> SUBROUTINE S(N)
> DIMENSION A(N), B(N)
> READ*,ISTART,ISTOP,B
> DO I = ISTART, ISTOP
> A(I) = B(I)
> ENDDO
> PRINT*,A
> END
>
> when compiled thusly:
>
> $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -
> msse2 vect4.f
>
> draws the following "not vectorized" message:
>
> vect4.f:4: note: not vectorized: complicated access pattern.
> vect4.f:4: note: vectorized 0 loops in function.
I get the following, using the autovect branch compiler on
x86_64-unknown-linux-gnu:
vect4.f:4: note: = analyze_loop_nest =
vect4.f:4: note: === vect_analyze_loop_form ===
vect4.f:4: note: split exit edge.
vect4.f:4: note: === get_loop_niters ===
vect4.f:4: note: ==> get_loop_niters:() (D.813_29 - i_27) + 1
vect4.f:4: note: Symbolic number of iterations is () (D.813_29 -
i_27) + 1
vect4.f:4: note: === vect_analyze_data_refs ===
vect4.f:4: note: get vectype with 4 units of type real4
vect4.f:4: note: vectype: vector real4
vect4.f:4: note: get vectype with 4 units of type real4
vect4.f:4: note: vectype: vector real4
vect4.f:4: note: === vect_analyze_scalar_cycles ===
vect4.f:4: note: Analyze phi: HEAP.49_363 = PHI ;
vect4.f:4: note: virtual phi. skip.
vect4.f:4: note: Analyze phi: HEAP.42_259 = PHI ;
vect4.f:4: note: virtual phi. skip.
vect4.f:4: note: Analyze phi: HEAP.35_60 = PHI ;
vect4.f:4: note: virtual phi. skip.
vect4.f:4: note: Analyze phi: i_1 = PHI ;
vect4.f:4: note: Access function of PHI: {i_27, +, 1}_2
vect4.f:4: note: step: 1, init: i_27
vect4.f:4: note: Detected induction.
vect4.f:4: note: === vect_pattern_recog ===
vect4.f:4: note: === vect_mark_stmts_to_be_vectorized ===
vect4.f:4: note: init: phi relevant? HEAP.49_363 = PHI ;
vect4.f:4: note: init: phi relevant? HEAP.42_259 = PHI ;
vect4.f:4: note: init: phi relevant? HEAP.35_60 = PHI ;
vect4.f:4: note: init: phi relevant? i_1 = PHI ;
vect4.f:4: note: init: stmt relevant? :
vect4.f:4: note: init: stmt relevant? D.830_39 = (int8) i_1
vect4.f:4: note: init: stmt relevant? D.831_40 = D.830_39 + -1
vect4.f:4: note: init: stmt relevant? D.832_43 = (*b_10)[D.831_40]
vect4.f:4: note: init: stmt relevant? (*a_16)[D.831_40] = D.832_43
vect4.f:4: note: vec_stmt_relevant_p: stmt has vdefs.
vect4.f:4: note: mark relevant 2, live 0.
vect4.f:4: note: init: stmt relevant? i_45 = i_1 + 1
vect4.f:4: note: init: stmt relevant? if (i_1 == D.813_29) goto ; else
goto ;
vect4.f:4: note: init: stmt relevant? :
vect4.f:4: note: worklist: examine stmt: (*a_16)[D.831_40] = D.832_43
vect4.f:4: note: vect_is_simple_use: operand D.832_43
vect4.f:4: note: def_stmt: D.832_43 = (*b_10)[D.831_40]
vect4.f:4: note: type of def: 2.
vect4.f:4: note: worklist: examine use 2: D.832_43
vect4.f:4: note: mark relevant 2, live 0.
vect4.f:4: note: worklist: examine stmt: D.832_43 = (*b_10)[D.831_40]
vect4.f:4: note: === vect_analyze_data_refs_alignment ===
vect4.f:4: note: vect_compute_data_ref_alignment:
vect4.f:4: note: Unknown alignment for access: *b_10
vect4.f:4: note: vect_compute_data_ref_alignment:
vect4.f:4: note: Unknown alignment for access: *a_16
vect4.f:4: note: === vect_determine_vectorization_factor ===
vect4.f:4: note: ==> examining statement: :
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.830_39 = (int8) i_1
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.831_40 = D.830_39 + -1
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.832_43 = (*b_10)[D.831_40]
vect4.f:4: note: vectype: vector real4
vect4.f:4: note: nunits = 4
vect4.f:4: note: ==> examining statement: (*a_16)[D.831_40] = D.832_43
vect4.f:4: note: vectype: vector real4
vect4.f:4: note: nunits = 4
vect4.f:4: note: ==> examining statement: i_45 = i_1 + 1
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: if (i_1 == D.813_29) goto ; else
goto ;
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: :
vect4.f:4: note: skip.
vect4.f:4: note: === vect_determine_vectorization_factor ===
vect4.f:4: note: ==> examining statement: :
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.830_39 = (int8) i_1
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.831_40 = D.830_39 + -1
vect4.f:4: note: skip.
vect4.f:4: note: ==> examining statement: D.832_43 = (*b_10)[D.831_40]
vect4.f:4: note: vectype: vector real4
vect4.f:4:
Re: Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.
On Friday 21 October 2005 09:51, Toon Moene wrote: > So where does the compiler lose this valuable information ? > Toon, could you open PRs for these problems? Some of the failures you see look like aliasing problems. It'd be nice to have them in bugzilla, even if they end up being dups of existing reports. I'll try. Unfortunately, I'm still working on a text-only basis (this is what you get when you want Debian Sarge AMD64 on a brand new laptop - I'm not complaining). I'll see if I can manipulate bugzilla this way via lynx. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: svn tag inspection
Jeffrey A Law <[EMAIL PROTECTED]> wrote: >> In fact, after the subversion conversion is over, we can "svn >> delete" all those merging tags for good since they're there because >> you can't delete them in CVS but we really don't need them anymore >> (before anybody asks: "svn delete" keeps history of course). > Just a minor correction, you can certainly delete cvs tags. It > just isn't something I'd necessarily recommend doing :-) > > cvs tag -d I think that is not a versioned operatoin (but I might be wrong). The point is that with svn you can remove all those tags as versioned operations, so you are really not destroying past history, and you're making the tags list much more meaningful and useful for everyday use. IMO we should do the same with closed branches, they really serve no purpose there in /branches in the current revision, we can safely "svn rm" them (or move to a /branches/closed subdir). Giovanni Bajo
gcc-4.1-20051022 is now available
Snapshot gcc-4.1-20051022 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051022/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-10-22 17:43 UTC You'll find: gcc-4.1-20051022.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051022.tar.bz2 C front end and core compiler gcc-ada-4.1-20051022.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051022.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051022.tar.bz2 C++ front end and runtime gcc-java-4.1-20051022.tar.bz2 Java front end and runtime gcc-objc-4.1-20051022.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051022.tar.bz2The GCC testsuite Diffs from 4.1-20051015 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Offline
SVN killed my machine (just kidding). But my machine is dead so I will not able to commit my patches which were approved or approved in the next couple of days. I will still be able to check my email and look at some bugzilla stuff but not as much as before. Hopefully I can get my machine fixed soon. Thanks, Andrew Pinski
MIPS TLS relocation assembly code invalid from GCC-4.1...
I have spent the last couple of hours groking code and I am coming up empty on this one. I ran into this problem when trying to build the 'tst-tls10' test program from glibc. This is not a glibc problem, rather an issue with my library and kernel header files, I think. I have ported NPTL support from glibc into uClibc and I have tests 1-9 working for TLS relocations as well as some of the pthread test programs. I cannot even get tests 10-15 for TLS built because I get the errors: /tmp/cc0gotLY.s: Assembler messages: /tmp/cc0gotLY.s:99: Error: register value used as expression /tmp/cc0gotLY.s:136: Error: register value used as expression /tmp/cc0gotLY.s:173: Error: register value used as expression So, I compared the compiler output from the glibc and uClibc test programs and miraculously the only differences between the two is show below: --- tst-tls10.s 2005-10-22 11:55:37.852343750 -0500 +++ /build/crosstool-0.38/build/mips-unknown-linux-gnu/gcc-head-glibc-head/build-glibc/elf/tst-tls10.s 2005-10-22 11:08:07.546210750 -0500 @@ -70,7 +70,7 @@ rdhwr $3,$29 .setpop - lw $16,%gottprel($5)($28) + lw $16,%gottprel(a1)($28) nop addu$3,$16,$3 lb $4,0($3) @@ -104,7 +104,7 @@ rdhwr $3,$29 .setpop - lw $19,%gottprel($6)($28) + lw $19,%gottprel(a2)($28) nop addu$3,$19,$3 lb $4,0($3) @@ -138,7 +138,7 @@ rdhwr $3,$29 .setpop - lw $20,%gottprel($7)($28) + lw $20,%gottprel(a3)($28) nop addu$3,$20,$3 lb $4,0($3) @@ -425,4 +425,4 @@ .word 2 .word 0 .word 3 - .ident "GCC: (GNU) 4.1.0 20051021 (experimental)" + .ident "GCC: (GNU) 4.1.0 20050823 (experimental)" While the GCC version I am using for glibc is older, the newer version I am using for my uClibc work with binutils-2.16.1 which is the same for glibc. I am using 2.6.12 kernel headers for uClibc and 2.6.13-rc6 for glibc, but when I took a diff between them, I could see nothing that I felt would impact anything like that above. So, I began digging through GCC guts, but could not figure out why I get the symbolic register representations in the glibc compiled code and not in my stuff. Can anyone shed some light as to where I can begin looking for the issue? Thanks. -Steve
Re: Vectorizing HIRLAM NN.
Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren voordat je de problemen voorlegt aan de mailing-list. Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor? Gr. Steven On Oct 21, 2005 09:49 PM, Toon Moene <[EMAIL PROTECTED]> wrote: > L.S., > > As Dorit indicated - it's better to perform vectorization > experiments from the autovect branch. > > Further data on this with respect to the HIRLAM code base > will be based on builds off the autovect branch. > > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ > Steven Bosscher SUSE Labs
Re: Vectorizing HIRLAM NN.
On Oct 22, 2005 09:34 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote: > Some stuff that, needless to say, was in Dutch and intended for Toon only. Sorry, Gr. Steven
Re: Vectorizing HIRLAM NN.
Steven Bosscher wrote: Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren voordat je de problemen voorlegt aan de mailing-list. Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor? For [EMAIL PROTECTED] subscribers' pleasure, Babelfish proudly presents its english translation: If you want, I can help, however, a hand by e.e.a. at analyzeren before you present the problems to the mailing trick. Very interesting, as this works. DOES THE KNMI will use also effective gfortran or isn't we still long far enough for that? ;-)
Re: svn tag inspection
Giovanni Bajo wrote: Jeffrey A Law <[EMAIL PROTECTED]> wrote: In fact, after the subversion conversion is over, we can "svn delete" all those merging tags for good since they're there because you can't delete them in CVS but we really don't need them anymore (before anybody asks: "svn delete" keeps history of course). Just a minor correction, you can certainly delete cvs tags. It just isn't something I'd necessarily recommend doing :-) cvs tag -d I think that is not a versioned operatoin (but I might be wrong). It's not. The point is that with svn you can remove all those tags as versioned operations, so you are really not destroying past history, Just to make this completely clear: removing a tag in SVN simply means that you remove the tag rirectory in HEAD. The tag (directory) still exists in previous revisions, so you can still, e.g., do a diff between two deleted tags. However, by deleting obsolete tags, you reduce the size of the tags directory in HEAD, thus obviously speeding up any queries amongs the current tags. and you're making the tags list much more meaningful and useful for everyday use. IMO we should do the same with closed branches, they really serve no purpose there in /branches in the current revision, we can safely "svn rm" them (or move to a /branches/closed subdir). Giovanni Bajo -- -- Brane
