Re: what optimization can be expected?

[Tim Prince <TimothyPrince@xxxxxxxxxxxxx>]

Brian Budge wrote:
> I'm curious why fast-math is involved with vectorization?  This seems 
> flawed to me, since fast-math allows many "incorrect" optimizations 
> according to the IEEE 754 standard.  I can see the vectorization being 
> a good or bad idea, but hopefully it shouldn't be "unsafe".  
> strict-aliasing should already account for whether that is allowed or 
> not.  Am I missing something?  Lumping it in to the same category just 
> seems strange to me.  In fact, it would be interesting to know if 
> there could be a clean separation of the underlying optimizations of 
> fast-math to those which modify your actual floating point output in 
> ways that violate 754 vs those which break the C standard (setting 
> errno, etc...), but I suppose this is leading to a new topic.
>
> Thanks,
>   Brian
The people who worked on vectorization agreed with you up to a point.  A 
proposed option -fassociative-math would have enabled vectorization of 
sum reductions, without all the baggage of -ffast-math.  I have never 
seen a version of gcc which accepted that one.
In gfortran, -ffast-math doesn't turn on as many unsafe optimizations as 
it does in gcc or g++; it's not coincidental that a larger fraction of 
gfortran users want full vectorization and abrupt underflow.
The preferences of gcc/g++ vs gfortran community about -ffast-math were 
well hashed out on the lists, such as fortran@xxxxxxxxxxxx  Fortran 
decided that -ffast-math should not violate Fortran language standard 
(by ignoring parentheses, for example).  Fortran explicitly permits more 
re-association than C.  A sufficient group of gcc community wants 
-ffast-math to perform algebraic simplifications counter to language 
standards.
IEEE 754 doesn't say anything about association (those optimizations 
which would be affected by -fassociative-math).  If gfortran made a 
partial implementation of -fassociative-math, such that the changes in 
order of operations would be accepted for vectorized sum reductions, I 
assume it would not be allowed to violate parentheses.
Few C compilers have an option which takes a middle ground of enabling 
optimizations beyond C standard such as Fortran, both traditionally and 
by standard allows, without further excessively aggressive optimizations.
Commercial compilers typically have excessively aggressive optimizations 
on by default, or at least as a default part of -O3.
Tim