On Tue, 11 Nov 2003, Andrew Suffield wrote: > On Tue, Nov 11, 2003 at 09:24:35PM +1100, Hamish Moffatt wrote: > > On Mon, Nov 10, 2003 at 05:08:48PM -0600, Joe Wreschnig wrote: > > > Of course, I'm far from a compiler and chip design expert (or even > > > novice); this is what I remember from my classes last year. :) But it > > > shows how complicated optimizing compilers can get, and why you can't > > > say any optimization is always good/safe/faster/etc. The only truly safe > > > way to tell is extensive, controlled benchmarking. > > > > An optimisation that makes things unsafe or slower isn't an > > optimisation. The compiler shouldn't produce any code that is incorrect > > or slower. Of course, it can't stop you from taking a P4-optimised > > binary and running it on an Athlon. > > > > I think you could say that any optimisation is safe and not slower; > > otherwise it's not an optimisation. > > Mmm. -ffast-math and -funsafe-math-optimizations, off the top of my > head.
or -fstrict-aliasing, which won't work with waaay too much code out there, including (from warnings I see) a lot of kernel-level stuff, such as alsa. I must remember to start filing bugs everywhere I see those warnings. Ugh. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh