Re: Porposal: Floating-Point Options

[Robert Dewar <dewar at adacore dot com>]

Scott Robert Ladd wrote:
> To support different expectations, I suggest defining the following
> floating-point options for GCC. This is a conceptual overview; once
> there's a consensus the categories, I'll propose something more formal.
>
> -ffp-correct
>
> This option focuses code generation on mathematical correctness,
> portability, and consistency. No 80-bit long doubles, no fsin/fcos,
> making certain that comparison operators work within reason. Note that
> this option can only go so far in ensuring portability, given that not
> every system supports IEEE 754 floats.

It is wrong, confusing, and provocative to call this correct, since
there is no justification for using this term, and it implies that
the current behavior of gcc is incorrect, which is not the case.
Choosing a good name for this is in fact not so easy
> -ffp-ieee754
>
> To the best of our ability, assume and follow IEEE 754. Similar to the
> above, but assuming IEEE floats and doubles. Note that IEEE 754 has been
> undergoing some revision.

754 (these days you really mean 854 or the corresponding ISO standard I
think) has little to say about mapping to high level languages, so it is
important to understand that appealing to this standard is necessary
but far from efficient.

Note that this could have disastrous effects on efficiency on the x86,
since it would require something similar to -fstore-float, since you
have to check range as well as precision to be strict IEEE.

For most people, the issue is avoiding the use of IEEE extended, and
mapping the precision as expected. Most people don't care if they get
the extended range that will fall out naturally. This gives a mode of
operation that has little or no speed penalty, unlike the full IEEE
adherence.
> -ffp-balanced (default)
>
> Balance correctness with speed, enabling performance optimizations that
> may reduce portability or consistency, but which do not alter the
> overall quality of results. Yeah, I know that's a bit fuzzy; formal
> definition of such an option depends on categorizing existing FP code
> generation (something I'm working on).

I would say this should be -ffp-standard, since it corresonds to normal
correct implementation of the C standard. I find the fuzziness you attempt
to introduce to be confusing here.
> -ffp-damn-the-torpedoes-full-speed-ahead
>
> Okay, maybe that should be something shorter, like -ffast-math or
> -ffp-fast. This option enables dangerous hardware intrinsics, and
> eschews all concerns about portability and consistency in the quest for
> speed. The behavior is likely to be the same as the current -ffast-math.

You don't want to be too negative in choosing a name for this. fast-math
is quite fine. There are many people who are never going to do careful
error analysis on their fp code, and for whom fp is simply a crude
approximation of real arithmetic, and just how approximate it is,
they don't know and don't care much.