Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2
On 22.02.2010 22:41, Janis Johnson wrote: On Mon, 2010-02-22 at 13:11 -0800, Andrew Pinski wrote: On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson wrote: If you can reproduce the problem with a small, self-contained test then please file a bug report. It might be possible to issue a warning or to detect that the loop should not be vectorized. If not, maybe the compiler should disable vectorization for -fno-strict-aliasing. It is not an aliasing issue but an alignment issue. Anyways this is most likely the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009 . Yes, that's the problem I had in mind but I was thinking about an explicit cast to a pointer to more-aligned data in the function that has the vector loop. There's no way to warn about the undefined behavior when the cast is in a different source file. It's interesting that two reports of failure due to this same undefined behavior come so close together. I wonder if it might be feasible to have a flag which inserts code to check for alignment assumptions and complain if they're not met, to check for things like this. (And then possibly to insert similar code for other assumptions gcc makes that are fairly easy to check at runtime.) Not alternate code paths, just something like an assert that the code behaves like gcc feels justified in assuming it should, and the programmer didn't do anything stupid - as long as it's fairly simple to check, such as the actual alignment of a pointer or perhaps the actual limit of a loop or some such; and as long as the assumption actually influences code generation decisions.
A 2 % gain for the past week on my code.
L.S., In the past week, changes to GNU Fortran / GCC brought me a 4 minute gain in a 3.5 hour weather forecast (run 4 times a day on my home computer - see http://moene.org/~hirlam/) 4 minutes on 210 minutes is ~ 2 % - not bad for such a diverse code. Without digging deeper in it (for which I have little time) it is impossible to say what change in the past week "made the difference" (if even it is just one). Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: A 2 % gain for the past week on my code.
Toon, I would suspect this boost is from the series of changes to "Update default arch for x86" from HJ Lu. This should now have -msse2 in use as the default (except on darwin where we went to -msse3 since all of our processors support that). Jack On Sun, Mar 07, 2010 at 07:34:22PM +0100, Toon Moene wrote: > L.S., > > In the past week, changes to GNU Fortran / GCC brought me a 4 minute > gain in a 3.5 hour weather forecast (run 4 times a day on my home > computer - see http://moene.org/~hirlam/) > > 4 minutes on 210 minutes is ~ 2 % - not bad for such a diverse code. > > Without digging deeper in it (for which I have little time) it is > impossible to say what change in the past week "made the difference" (if > even it is just one). > > Cheers, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/ > Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: A 2 % gain for the past week on my code.
Jack Howarth wrote: Toon, I would suspect this boost is from the series of changes to "Update default arch for x86" from HJ Lu. This should now have -msse2 in use as the default (except on darwin where we went to -msse3 since all of our processors support that). That could well be. I now configure as follows: --with-arch-64=native --with-tune-64=native as opposed to: --with-arch-64=core2 --with-tune-64=core2 previously. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: A 2 % gain for the past week on my code.
On Sun, Mar 07, 2010 at 08:17:54PM +0100, Toon Moene wrote: > Jack Howarth wrote: > >> Toon, >>I would suspect this boost is from the series of changes >> to "Update default arch for x86" from HJ Lu. This should now >> have -msse2 in use as the default (except on darwin where >> we went to -msse3 since all of our processors support that). > > That could well be. I now configure as follows: > > --with-arch-64=native --with-tune-64=native > > as opposed to: > > --with-arch-64=core2 --with-tune-64=core2 > > previously. > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/ > Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html Toon, My benchmarks for the polyhedron 2005 benchmarks on x86_64-apple-darwin10 confirmed HJ Lu's observations on darwin that the core2 tuning actually perform worse than generic tuning... http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01272.html Hopefully FSF gcc will eventually fix this so that processor specific costs actually improve the benchmarks. Jack
gcc-4.3-20100307 is now available
Snapshot gcc-4.3-20100307 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100307/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 157266 You'll find: gcc-4.3-20100307.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100307.tar.bz2 C front end and core compiler gcc-ada-4.3-20100307.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100307.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100307.tar.bz2 C++ front end and runtime gcc-java-4.3-20100307.tar.bz2 Java front end and runtime gcc-objc-4.3-20100307.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100307.tar.bz2The GCC testsuite Diffs from 4.3-20100228 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
How to make 'long int' type be a PDImode?
Hi, I'd like to make a backend which would have 48 bits for 'long' type. (32 for int and 64 for long long). I have tried to define: #define LONG_TYPE_SIZE 48 and one of: INT_MODE (PDI, 6); PARTIAL_INT_MODE (DI); Unfortunately, trying to compile a program, I see that the backend still uses SImode for 'long'. I could not find an example for target doing similar work. Could you please advise or show the location of implementation I can refer? Thank you, Frank
Re: How to make 'long int' type be a PDImode?
Quoting Frank Isamov : Hi, I'd like to make a backend which would have 48 bits for 'long' type. (32 for int and 64 for long long). I have tried to define: #define LONG_TYPE_SIZE 48 That's not a partial integer mode; PDImode would have the same size as DImode, just not all bits would be significant. and one of: INT_MODE (PDI, 6); And that wouldn't be PDImode, more like THImode (three-halves integer mode, going by the precedent of TQFmode - three-quarter float mode - of the 1750a port in GCC prior to version 3.1)
