Porposal: Floating-Point Options

[Marcin Dalecki]

On 2005-06-14, at 16:32, 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

Please define correct.

> This option focuses code generation on mathematical correctness,
> portability, and consistency.

Please define this. Please define mathematical correctness for a FPU  
implementation.
Preferable in formal terms. A Verilog file for example wold be fine.  
Don't forget
to perform *full* verification of the design to be. I mean in  
mathematical terms.
Seriously, I don't mind if this will take a tad bit of time.
Please lay down in esp. how GCC currently deviates from the  
principles in this statement.

> No 80-bit long doubles, no fsin/fcos,
> making certain that comparison operators work within reason.

Please give the definition of reason.

> Note that this option can only go so far in ensuring portability,  
> given that not
> every system supports IEEE 754 floats.

Please give the distance for "so far". Preferable in metric terms.

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

Note taken. I hence forth declare to have no abilities. Thus this  
goal is
immediately accomplished. Note that you can derive your own abilities  
from
this statement.

> -ffp-balanced (default)

Yes. My iMac is already well balanced on the aluminum tadpole on  
which it sits.

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

Yeah just a tad little bit... we can stop considering minor stuff  
like cache sizes
RAM latencies versus clock rate and all those other minor irrelevant
stuff which doesn't allow us to define a single only total optimum  
for the generated code.
You are right - this kind of nit-picking is really fully irrelevant  
for the
task at hand.

> formal
> definition of such an option depends on categorizing existing FP code
> generation (something I'm working on).
>
> -ffp-damn-the-torpedoes-full-speed-ahead

I just love cute references to military terms. I served myself  
proudly but
involuntarily in the ari. You know buddy. They just make me feel like...
actually like... oh dare memories.

> Okay, maybe that should be something shorter,

How about:
-ffp-damn-I-have-no-clue

Nearly half the size - you see?

> like -ffast-math or
> -ffp-fast. This option enables dangerous hardware intrinsics,

Will it pose the danger for overheating my CPUs thermal throttling?
Perhaps it should be accompanied with an interactive question asserting
question at compiler run time then:

gcc -ffp-fast helloworld.c
ALLERT: The -ffp-fast option is dangerous. Are you sure to proceed  
[YES/NO]?:

> 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.
>
> Actually, I like *-ffp-damn-the-torpedoes-full-speed-ahead*.

I love it too...

> As Stroustrup once said, if you're going to do somethimg ugly, it  
> should
> look ugly. ;)

Yes! The road to success is paved with imitation. Success is always
reproducible and not accidental. And I'm sure Stroustrup was a better  
philosopher
then coder, since competence in one area automatically projects  
itself on
everything...