-
Notifications
You must be signed in to change notification settings - Fork 38
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.
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
Use simpler ops for binary instructions (fixes GCC issue) #513
Conversation
Codecov Report
@@ Coverage Diff @@
## master #513 +/- ##
=======================================
Coverage 99.69% 99.69%
=======================================
Files 54 54
Lines 17183 17198 +15
=======================================
+ Hits 17131 17146 +15
Misses 52 52 |
template <typename T> | ||
inline constexpr T add(T a, T b) noexcept | ||
{ | ||
return a + b; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer we add the asserts for is_integral||is_float to avoid any random overloading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is big overkill and still is not complete (as bool
, char
, long double
would be a match). I can't imagine accidentally adding two things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Realistically what could happen is that Value is overloaded and this matches for Value+Value. Why would it be an overkill?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is perfectly valid for any type that is copyable and has + operator. The Value
does not support + operator as of #464. Also all usages of it explicitly specify the type.
} | ||
|
||
template <typename T> | ||
inline constexpr T rem(T a, T b) noexcept |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not call it mod
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because i32.rem_s
So it was a problem only for Do we replace |
The problem seems to be only for add. But I replaced also other functions in the same group (arithmetic binops). |
I'm getting significant boost with it (with clang)
|
Oh, nice. I will check my machine soon. |
This replaces usage of std::plus{} and others with simpler in-house implementation. The difference is that the std:: versions are passing arguments by reference. In GCC builds without optimization this may cause the arguments to be swapped in commutative instructions. This is at least annoyance for floating-point add which may produce different NaN results if both inputs are NaNs. This is not a problem for Wasm conformance, but prevents running exhaustive tests against software floats implementations.
I checked GCC10 and Clang10 and both generate unchanged assembly. |
This replaces usage of std::plus{} and others with simpler in-house
implementation. The difference is that the std:: versions are passing
arguments by reference. In GCC builds without optimization this may
cause the arguments to be swapped in commutative instructions. This is
at least annoyance for floating-point add which may produce different
NaN results if both inputs are NaNs. This is not a problem for Wasm
conformance, but prevents running exhaustive tests against software
floats implementations.