Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nearbyhint: Fix for ffast-math #550

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

nearbyhint: Fix for ffast-math #550

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 35 additions & 11 deletions include/xsimd/arch/generic/xsimd_generic_math.hpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1707,6 +1707,40 @@ namespace xsimd {
}


#if !defined(__FAST_MATH__)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now on $DAILY_JOB.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

template <class T>
T conformant_add_then_sub (T x, T v)
{
return x + v - v;
}
#else
#if defined(__clang__)
// available on clang 4
#define XSIMD_NO_OPTIMIZATION_ATTRIBUTE __attribute__((optnone))
#define XSIMD_NO_OPTIMIZATION_PRAGMA
#elif defined(__GNUC__)
// available on GCC 4.9
#define XSIMD_NO_OPTIMIZATION_ATTRIBUTE __attribute__((optimize("O0")))
#define XSIMD_NO_OPTIMIZATION_PRAGMA
#elif defined(_MSC_VER)
// available Visual Studio 2015
#define XSIMD_NO_OPTIMIZATION_ATTRIBUTE
#define XSIMD_NO_OPTIMIZATION_PRAGMA __pragma(optimize("", off))
#else
// Under fast-math, the compiler will assume (x - v + v = x).
//
// This error is hit it is because you are using an unsuported compiler.
// Consider submitting a patch, as workaunding it is easy.
#error "Unoptimized version of x + y - y required. See the code for details."
#endif
XSIMD_NO_OPTIMIZATION_PRAGMA
template <class T>
XSIMD_NO_OPTIMIZATION_ATTRIBUTE T conformant_add_then_sub (T x, T v)
{
return x + v - v;
}
#endif

// nearbyint
template<class A, class T, class=typename std::enable_if<std::is_integral<T>::value, void>::type>
batch<T, A> nearbyint(batch<T, A> const& self, requires_arch<generic>) {
Expand All @@ -1718,16 +1752,7 @@ namespace xsimd {
batch_type s = bitofsign(self);
batch_type v = self ^ s;
batch_type t2n = constants::twotonmb<batch_type>();
// Under fast-math, reordering is possible and the compiler optimizes d
// 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;
#else
batch_type d0 = v + t2n;
batch_type d = d0 - t2n;
#endif
batch_type d = conformant_add_then_sub (v, t2n);
return s ^ select(v < t2n, d, v);
}
}
Expand Down Expand Up @@ -2199,4 +2224,3 @@ namespace xsimd {
}

#endif