Polyhedron tests on Intel Darwin8/9

[Tim Prince]

Janne Blomqvist wrote:
> Dominique Dhumieres wrote:
>> with a fmadds corresponding to 's = s + a1*b1'.
>> So even at -O3 the gcc optimizer is unable to see that
>> a1*b1 is always zero, even if b1 is a constant 
> 
> As Andrew hinted at, you can't optimize away this without breaking IEEE
> 754 conformance. Try -ffast-math.
> 
> Now, I suppose one could argue that Fortran != IEEE 754, and that
> Fortran allows mathematically equivalent transformations, so by default
> gfortran should be a little bit looser than gcc (not as loose as
> everything in -ffast-math though). However, there has been discussion
> about FP optimization in gcc in general, so perhaps gfortran should wait
> for some kind of consensus there before doing any drastic changes. See
> 
> http://gcc.gnu.org/wiki/FP_BOF
> 
> http://gcc.gnu.org/wiki/GeertBosch
> 
> http://gcc.gnu.org/wiki/Math_Optimization_Flags
> 
One of those URLs asks about dot product optimization, but doesn't
mention that it happens now for sse vectorized platforms only under
-mfpmath=sse -ffast-math.  There was an announcement of a flag which
would enable this outside of -ffast-math, but I couldn't find any
evidence of implementation.
According to my understanding, the optimization inherent in
vectorization of sum reductions is fully allowable under Fortran (but
not C) standards, and is not addressed by IEEE754.  gfortran already has
a few special optimization flags which are on by default, but are not on
by default in C, such as -fargument-noalias, so it seems there is a
precedent which would allow this to be considered as a default
optimization for gfortran. It would be a default only under -O3, in that
vectorization doesn't come on by default except with -O3.
I find it intolerable that normal optimizations are linked inextricably
with unsafe ones.  I do agree with the position of gcc/gfortran that
risky optimizations aren't there by default.
ifort has reached a satisfactory position only recently, where a
combination of options such as -assume protect_parens -prec-div
-prec-sqrt is available, which turns off the most risky options, while
leaving practically all vectorization options on.  It doesn't hurt that
the current CPUs aren't so dependent on the non-IEEE divide and sqrt
replacements.
The cases where flat-out optimization makes bad decisions about ignoring
parentheses are being chipped away also (-ffast-math has some).  Short
of poorly written source code, I can't see an adequate excuse for
violating parens even at the most aggressive optimization levels.