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