[MauranKilom]

> The second code can probably become SIMD as well, but it's beyond GCC's ability to autovectorizer it in that form.

Usually, for floating point operations the compiler simply has no chance to do anything clever. NaNs, infinities and signed zero mean that even the most "obvious" identities don't actually hold. For example, x + 0 == x (where the == is bitwise) does not hold for x = -0.

[sampo]

> For example, x + 0 == x (where the == is bitwise) does not hold for x = -0.

But when operating on floating point numbers, == is not bitwise, and -0 == +0.

[MauranKilom]

If the user provides code where the result should be +0.0 and the compiler emits code that results in -0.0 (and the user has not explicitly enabled relaxed IEEE754 conformance), that's a bug in the compiler.

[sampo]

That is correct. But we were talking about how the == operator compares zeros. According to IEEE 754, -0 == +0 even though their bit patterns are not identical. And, by the way, inf != inf even if their bit patterns are identical.

[MauranKilom]

> But we were talking about how the == operator compares zeros

Well, you were and I wasn't, and it wasn't clear whether you meant to contradict my point. I guess I could've made it more clear that I meant "using == to denote bitwise equality here only" and not "btw, == is bitwise for floats", but either way it should be clear now.

[andreareina]

You mean nan right?

[sampo]

Yes. I mean nan != nan. I don’t know why I wrote inf. Thank you for correcting.

[Someone]

That doesn’t matter for the case where a compiler would like to replace x + y by x because it knows y == 0.

The compiler would have to test for the x == -0 case, and doing that ¿rarely/never? is faster than computing x + y.

[titzer]

TurboFan does reason about whether a value can be -0 and will strength reduce if it's known a -0 will not occur. Further, it reasons about observations of a value; if it is known that a -0 is never observed, e.g. the value is only ever converted to an integer, or compared, or otherwise only flows into expressions that treat 0 == -0, then it will do more aggressive optimizations.

[anticensor]

There is a compiler switch for that too: -fassociative-math -funsafe-math-optimizations

[Izkata]

I like how the flag combines in that second one to create "fun safe", pretty much flipping its meaning.

[andi999]

so x+0 is 0?

[ncmncm]

No. -0.0 + 0 is not necessarily bitwise-equal to 0.0. Though it arguably could be, depending on details.

[Sesse__]

-0.0 + x = x, even if x should be -0.0 or +0.0.

+0.0 + x, on the other hand, is not always equal to x.

[titzer]

Note that IEEE 754 defines exactly which zero you get in every combination of operands. -0 + 0 is actually 0.