GCC Bugzilla Bug 28684

Hi,

I'm reporting a definitional problem with the -funsafe-math-optimization flag. 
This problem was initially discussed in comments 55-63 of bugzilla 27827.  I
will attempt to summarize that discussion here.

Here's the definition of -funsafe-math-optimizations from the manpage:
|      -funsafe-math-optimizations
|          Allow optimizations for floating-point arithmetic that (a) assume
|          that arguments and results are valid and (b) may violate IEEE or
|          ANSI standards.

From those prior discussions, it seems to me that unsafe does not currently
violate any IEEE (by which I mean IEEE 754, the floating point standard) rules
(with the exception of use of recipricols, which is handled below).  Rather, it
violates ANSI/ISO C rules, in particular those involved in enforcing order. 
This distinction is overwhelmingly important, because I can certify my code to
be correct in the face of reordering by examining the code, but nothing I do in
the code protects me if IEEE is violated.  This is because IEEE is the contract
that specifies what it means to do a flop (floating point operation) such as
a+b or a*b.  If this contract is violated, I have no way of understanding what
floating point does, which means theory cannot bound the error in my answer,
nor is there a way to find out if exceptional events have occured (examples of
transformations that truly violate IEEE are using 3DNow! or turning off IEEE
compliance in SSE).

People who do general floating point computation must therefore always maintain
IEEE compatability, but are often able to allow reorderings.  Unfortunately, at
the present time, -funsafe is *required* in order to enable vectorization
(because vectorization almost always reorders the operations).  This means that
computational scientists in the main will not be able to use gcc's
vectorization, even though vectorization is of key importance to this group.

My first suggestion is to redefine unsafe to more fully explain what it does,
so that gcc's users can certify it safe for a particular piece of code.  Here
is a proposed definition that will allow this set of optimizations to be
enabled by a computational guy like myself:
|      -funsafe-math-optimizations
|          Allow optimizations for floating-point arithmetic that require
|          reordering floating-point operations and/or the use of recipricols
|          (eg. a/b --> a*(1/b) or a+b+c --> a+c+b)
|          NOTE: may reorder or strength reduce floating-point comparisons as
|          well, and so may not be used when ordered comparisons are required

With this definition, I can examine my code, and not throw this flag if my code
can't handle it.  In the prior one, I cannot certify my code to work with the
the flag no matter what I do.  I believe from the prior discussions that this
definition of the flag will contain all the transformations presently enabled
by this flag.  I'm sure this is not the best definition, but it is an example
that would allow the knowledge to be used by a computational scientist.

The less general solution is to have a separate flag for allowing vectorization
(or better, all reordering optimizations), which specifies that it can reorder
the data, since this would allow vectorization to be used by computational
scientists.  This is good enough for me, but I believe more usefully defining
-funsafe is the best choice because the people most likely to want to throw
-funsafe are computational scientists, and the present definitions essei,

I'm reporting a definitional problem with the -funsafe-math-optimization flag. 
This problem was initially discussed in comments 55-63 of bugzilla 27827.  I
will attempt to summarize that discussion here.

Here's the definition of -funsafe-math-optimizations from the manpage:
|      -funsafe-math-optimizations
|          Allow optimizations for floating-point arithmetic that (a) assume
|          that arguments and results are valid and (b) may violate IEEE or
|          ANSI standards.

From those prior discussions, it seems to me that unsafe does not currently
violate any IEEE (by which I mean IEEE 754, the floating point standard) rules
(with the exception of use of recipricols, which is handled below).  Rather, it
violates ANSI/ISO C rules, in particular those involved in enforcing order. 
This distinction is overwhelmingly important, because I can certify my code to
be correct in the face of reordering by examining the code, but nothing I do in
the code protects me if IEEE is violated.  This is because IEEE is the contract
that specifies what it means to do a flop (floating point operation) such as
a+b or a*b.  If this contract is violated, I have no way of understanding what
floating point does, which means theory cannot bound the error in my answer,
nor is there a way to find out if exceptional events have occured.

People who do general floating point computation must therefore always maintain
IEEE compatability, but are often able to allow reorderings.  Unfortunately, at
the present time, -funsafe is *required* in order to enable vectorization
(because vectorization almost always reorders the operations).  This means that
computational scientists in the main will not be able to use gcc's
vectorization, even though vectorization is of key importance to this group.

My first suggestion is to redefine unsafe to more fully explain what it does,
so that gcc's users can certify it safe for a particular piece of code.  Here
is a proposed definition that will allow this set of optimizations to be
enabled by a computational guy like myself:
|      -funsafe-math-optimizations
|          Allow optimizations for floating-point arithmetic that require
|          reordering floating-point operations and/or the use of recipricols
|          (eg. a/b --> a*(1/b) or a+b+c --> a+c+b)
|          NOTE: may reorder or strength reduce floating-point comparisons as
|          well, and so may not be used when ordered comparisons are required

With this definition, I can examine my code, and not throw this flag if my code
can't handle it.  In the prior one, I cannot certify my code to work with the
the flag no matter what I do.  I believe from the prior discussions that this
definition of the flag will contain all the transformations presently enabled
by this flag.  I'm sure this is not the best definition, but it is an example
that would allow the knowledge to be used by a computational scientist.

The less general solution is to have a separate flag for allowing vectorization
(or better, all reordering optimizations), which specifies that it can reorder
the data, since this would allow vectorization to be used by computational
scientists.  This is good enough for me, but I believe more usefully defining
-funsafe is the best choice because the people most likely to want to throw
-funsafe are computational scientists, and the present definitions essentially
says they cannot ever enable it.

Thanks,
Clint

Confirmed.  I think we should split at least the reassociation and reciprocals
from -funsafe-math-optimizations, as for example on x86 we create fsin/fsincos
and friends which are of lower precision than required.

Richard,

Thanks for confirmation.  There's no chance of this happening soon, I guess? 
I'm working on a release of ATLAS (fast linear algebra), and I can't enable gcc
vectorization until its necessary flags are separated from the non-IEEE badness
. . .

Thanks,
Clint

It probably will not happen before 4.3 and, even if it happened for 4.2, it
will never be backported to 4.1 since this one is in regression fixes-only
mode.

You could help by looking at the source code (there are only a few dozens
places mentioning flag_unsafe_math_optimizations) and auditing which places
would be more suited to a new flag_reassociate_fp variable.

> You could help by looking at the source code (there are only a few dozens
> places mentioning flag_unsafe_math_optimizations) and auditing which places
> would be more suited to a new flag_reassociate_fp variable.

we'd be very interested in allowing the vectorizer to work under
flag_reassociate_fp rather than flag_unsafe_math_optimizations, so we'll give
this a try. 

Hi,

Following Dorit's comment; We thought of starting this journey with a patch
that include the cases in the vectorizer and loop-unroll and gradually add the
rest of the cases that can go under flag_reassociate_fp.

Revital

I would also like to be assigned to this bug.

Thanks,
Revital

Subject: Bug number PR 28684

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00110.html

(In reply to comment #6)
> I would also like to be assigned to this bug.
> 
> Thanks,
> Revital
> 

Done.

(In reply to comment #7)
> Subject: Bug number PR 28684
> 
> A patch for this bug has been added to the patch tracker.
> The mailing list url for the patch is
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00110.html
> 

I think you should ping your patch from time to time if you wish it to be
reviewed. It seems it went by unnoticed.

*** Bug 32172 has been marked as a duplicate of this bug. ***

The patch was committed to r128075.

Revital