4 ms·

> 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

> 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 4y ago
> 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.
- Someone 4y ago
  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 4y ago
    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.
- MauranKilom 4y ago
  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 4y ago
    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.
    - andreareina 4y ago
      You mean nan right?
      - sampo 4y ago
        Yes. I mean nan != nan. I don’t know why I wrote inf. Thank you for correcting.
    - MauranKilom 4y ago
      > 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.
andi999 4y ago
so x+0 is 0?
- ncmncm 4y ago
  No. -0.0 + 0 is not necessarily bitwise-equal to 0.0. Though it arguably could be, depending on details.
  - Sesse__ 4y ago
    -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 4y ago
    Note that IEEE 754 defines exactly which zero you get in every combination of operands. -0 + 0 is actually 0.
anticensor 4y ago
There is a compiler switch for that too: -fassociative-math -funsafe-math-optimizations
- Izkata 4y ago
  I like how the flag combines in that second one to create "fun safe", pretty much flipping its meaning.

sampo 4y ago

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

Someone 4y ago
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 4y ago
  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.
MauranKilom 4y ago
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 4y ago
  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.
  - andreareina 4y ago
    You mean nan right?
    - sampo 4y ago
      Yes. I mean nan != nan. I don’t know why I wrote inf. Thank you for correcting.
  - MauranKilom 4y ago
    > 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.

andi999 4y ago

so x+0 is 0?

ncmncm 4y ago
No. -0.0 + 0 is not necessarily bitwise-equal to 0.0. Though it arguably could be, depending on details.
- Sesse__ 4y ago
  -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 4y ago
  Note that IEEE 754 defines exactly which zero you get in every combination of operands. -0 + 0 is actually 0.

anticensor 4y ago

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

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