nearbyhint: Fix for ffast-math

[RafaGago]

See commit text.

This fixes:
#548

Notice that I wasn't able to verify it on Visual Studio, just g++ and clang.

[serge-sans-paille]

Interesting approach! I wonder if the following works as expected and is faster or not:

namespace details {
template<class T>
T force_add(T x, T y) {
#if defined(__FAST_MATH__) && (defined(__clang__) || defined(__GNUC__))
__attribute__((noinline))
#endif
    return x + y;
}
}

then call it appropriately

[RafaGago]

Now on $DAILY_JOB.

Without trying I'd say that a competent compiler will still optimize it away.

[RafaGago]

But notice that the optimization we want to break is ffast-math related. Inlining should make no difference.

[serge-sans-paille]

Can you give a try to the following patch instead: if it works, it's much less intrusive

diff --git a/include/xsimd/arch/generic/xsimd_generic_math.hpp b/include/xsimd/arch/generic/xsimd_generic_math.hpp
index 56e4d98..2ef41de 100644
--- a/include/xsimd/arch/generic/xsimd_generic_math.hpp
+++ b/include/xsimd/arch/generic/xsimd_generic_math.hpp
@@ -1722,8 +1722,8 @@ namespace xsimd {
         // to v. That's not what we want, so prevent compiler optimization here.
         // FIXME: it may be better to emit a memory barrier here (?).
 #ifdef __FAST_MATH__
-        volatile batch_type d0 = v + t2n;
-        batch_type d = *(batch_type*)(void*)(&d0) - t2n;
+        volatile auto d0 = (v + t2n).data;
+        batch_type d = batch_type(d0) - t2n;
 #else
         batch_type d0 = v + t2n;
         batch_type d = d0 - t2n;

[RafaGago]

Now I'm at $DAILY_JOB I don't have the codebase at hand, but I'd say that local scope volatile variables are not enough to stop Clang. It seems that it sees through the intrinsic types, otherwise it woudn't have correctly applied the optimization.

The problem with the volatile approach, is that even if it worked now we don't know if a compiler update would silently break it.

Notice that to remove the volatile instead of doing "(batch_type)(void*)(&d0)" you can do "const_cast<batch_type const&> (d0)"

[serge-sans-paille]

#551 achieves the same result on my laptop, while being less intrusive on the codebase. Can you confirm it works for you too?