Floating point performance issue

[David Brown]

On 21/12/2011 09:31, Miles Bader wrote:
> 2011/12/21 David Brown<david@westcontrol.com>:
>> My impression was that they were the same, or at least related, since the
>> calculations in the examples would probably be done in advance by the
>> compiler and reduced to simple assignments.
>
> You can't depend on the values the compiler calculates at compile-time
> anymore than you can depend on values calculated at runtime (after
> all, a decent compiler will strictly emulate the behavior of the
> target hardware when doing constant folding).
>
> For constant values, especially those meeting certain criteria, things
> are simpler.  For instance, [positive] zero or smallish positive
> integer values can be exactly represented by any reasonable
> floating-point format, and no amount of copying around is going to
> change them, even given  typical FPU wackiness.
>
>> If the
>> compiler can guarantee consistent and expected results in cases like yours
>> involving simple assignments, then it would make sense to change the
>> "-Wfloat-equal" not to trigger in such situations.  After all, the point of
>> the warning is to help users avoid code that might not do what it seems to
>> do - if it /does/ do the expected thing, then there is no need of a warning.
>>
>> In other words, the best course (IMHO) is to fix -Wfloat-equal to eliminate
>> common false positives, and /then/ enable it by default.
>
> The problem is that in many cases you simply can't tell, because you
> don't know how a particular value was produced.
>
> For instance, if you have code like:
>
>     float var = zot ();
>     if (var == 0.f)
>        blahblah ();
>
> You often don't know what "zot" did to calculate it's return value.
> If it just did "return 0.f;", then you're golden -- the comparison is
> fine.  However, if it did "return 1.f - fsin (1.f);", wellllll.....
>
> One thing that might work would be to have the warning code look at
> the local context before the comparison, and only warn if it saw that
> one of values being compared is actually calculated, rather than being
> a constant or coming from some non-local source.  This would result in
> a lot of false negatives, but that's better than false positives.
>
> -miles
>

I understand the problem you are describing, and the challenges of it. 
But I think I disagree a little on what you describe as false positives, 
and how much of a problem they are.  Basically, I believe that if you 
can't be sure that the code is consistent and correct in all 
circumstances, including different optimisation levels, then it's bad 
code - and it is fair to give a warning.  So I would want a warning on 
your "zot" code regardless of how it is implemented - to my mind, that's 
not a false positive even if zot() were a macro expanding to "0.f". 
It's bad code style to rely on it, so give a warning.

I am more a fan of strict warnings than most people, and have often said 
most warnings should be enabled by default - though I know perfectly 
well that they won't be.  I'm just evangelising for safer coding 
practices, as I see them.  In reality, of course, I'll just keep the 
warning flag in my own makefiles.

mvh.,

David