Re: Porposal: Floating-Point Options

[Vincent Lefevre <vincent+gcc at vinc17 dot org>]

On 2005-06-14 10:32:57 -0400, 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.

Why no 80-bit long doubles if this has no effect on doubles?
And what about doubles? Remember that there are two problems:
one related to the internal precision and one related to the
type (precision and range).

I don't like the word "correct" here, since the correctness
depends very much on the context. Some applications may just
need a conforming C implementation, others just need an IEEE-754
conforming implementation, and others something stricter (e.g.
Java and related languages, which need more or less strict IEEE
double precision).

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

This isn't clear. Also note that IEEE 754 allows extended precision.

> -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 disagree. The default should be a conforming C99 implementation.
Users who want speed should either use options that would produce
non-conforming code or use a processor that allows faster generated
code (e.g. a non-x86 one or one with SSE2 instructions).

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

I think it would be simpler to think about individual compiler
"behaviors" related to floating-point code generation and group
them into classes later. I've said "behaviors", not "options",
since pragmas (standard or not) could be used to get different
behaviors.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA