Re: Polyhedron tests on Intel Darwin8/9

[Dorit Nuzman <DORIT at il dot ibm dot com>]

> 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.

maybe you mean -fassociative-math. The vectorizer now relies on
-fassociative-math instead of -ffast-math when considering vectorization of
fp reduction.

> 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.

I think people are trying to fix this. see
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01733.html

dorit

> 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.