This CL more or less reverts commit https://codereview.chromium.org/2107733002/
The use of the MathPow code stub that was introduced by that commit caused
problems on arm64, and the MathPow code stub was also an obstacle in the
implementation of parallel code generation.
In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64
which were turned off because of problems with MathPow on arm64.
R=titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2166793002
Cr-Commit-Position: refs/heads/master@{#37911}
This patch provides a new implementation of popcnt and ctz in the case
where the platform does not provide these instructions. Instead of
building a TF graph which implements it we now call a C function.
Additionally I turned on additional tests in test-run-wasm-64.cc
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1857363003
Cr-Commit-Position: refs/heads/master@{#35685}
1) I moved the implementations of the wrapper functions into a new cc
file so that I can use these wrapper functions in tests.
2) I made a generic test for all tests in
test-run-calls-to-external-references.cc. In the new test we only
compare the result of a function call through an external reference with
the result of a direct function call. This is sufficient because we only
want to test function calls through external references work here.
The implementation of these functions are tested somewhere else.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1853123002
Cr-Commit-Position: refs/heads/master@{#35289}
On 32-bit systems these instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameters is done in the
Int64Lowering. We use the return value of the C function to determine
whether the calculation should trap or not.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1804513002
Cr-Commit-Position: refs/heads/master@{#34768}
On 32-bit systems I64XConvertFXX instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering. We use the return value of the C function to determine
whether the conversion should trap or not.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1775903002
Cr-Commit-Position: refs/heads/master@{#34738}
Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced
a macro which first stores the expected result in a volatile variable.
Here are some comments of previous CLs:
The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
Here is the key comments from CL #31808
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i).
R=titzer@chromium.org, weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1773513002
Cr-Commit-Position: refs/heads/master@{#34534}
On 32-bit systems FXXXConvertI64 instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering.
R=titzer@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1738623003
Cr-Commit-Position: refs/heads/master@{#34487}
