Re: Porposal: Floating-Point Options

[Scott Robert Ladd <scott dot ladd at coyotegulch dot com>]

Marcin Dalecki wrote:
> Sorry but I just got completely fed up by the references to "math" by
> the original post, since the authors leak of basic experience in the
> area of numerical computation was more then self evident.

My apologies for not meeting your high intellectual standards, ;P

> Making the code generated by GCC somehow but not 100% compliant with
> some idealistic standard, will just increase the scope of the
> analysis you  will have to face. And in esp. changing behavior
> between releases will  just make it even worser.

Perhaps my understanding of math isn't as elite as yours, but I do know
that "worser" isn't a word. ;)

Then again, I *am* the fellow who started a thread with "Porposal" in
the title. It sounds like I'm making a suggestion about dolphins... :)

> Only the following options would make sense:
> 
> 1. An option to declare 100% IEEE compatibility if possible at all on
>  the particular arch, since it's a well known reference.
> 
> 2. An option to declare 100% FPU architecture exposure.
> 
> 3. A set of highly target dependent options to control some well
> defined features of a particular architecture. (Rounding mode,
> controll, use of MMX or SSE[1234567] for example...)

I would replace 3 above with:

3. When compiled without either of the above options, adhere strictly to
the relevant language standard.

Given that Java, Fortran 95, C and C++ all have differences in their
definitions of floating-point, this will need to be (as it already is,
to some extent) language-specific.

> Any kind of abstraction between point 1. and 2. and I would see
> myself analyzing the assembler output to see what the compiler
> actually did anyway.

On further reflection, I don't see how a middle ground can even be
defined. The three states above seem to make sense: IEEE, hardware, or
language standard.

> And last but not least: Most of this isn't really interesting at the 
> compilation unit level at all. This is the completely uninteresting
> scope. If anything one should discuss about the pragma directive
> level, since this is where fine control of numerical behavior happens
> in the world out there. The ability to say for example:
> 
> #pragma unroll 4 sturd 8
> 
> would be really of "infinite" more value then some fancy -fblah-blah.

GCC seems to have a fancy for options, since that is what most people
ask for. I agree that a set of "tuning" pragmas would be a good way of
defining the compilation requirements for a given algorithm.

I'm always open to friendly, intelligent conversation. Starting off by
being high-handed and insulting (as you did) accomplishes nothing.

..Scott