[Bug c/28684] New: Imprecise -funsafe-math-optimizations definition

["whaley at cs dot utsa dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

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


-- 
           Summary: Imprecise -funsafe-math-optimizations definition
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: whaley at cs dot utsa dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684