If the architecture does not provide rounding instructions, then C
implementations of these rounding instructions are called. The C
implementations from math.h are used, function pointers are registered
as external references so that they can be call from the simulator.
R=titzer@chromium.org
BUG=575379
LOG=Y
Review URL: https://codereview.chromium.org/1661463002
Cr-Commit-Position: refs/heads/master@{#33677}
Motivated by finding a bug in a larger module, this CL adds the ability
to dump out a byte-by-byte, nested view of the decoded AST. This
byte-by-byte output uses the opcode enum to make it readable, but is
suitable for pasting into a byte[] in C or JS and thus making a regression
test.
Also fix a bug; the case of running out of registers for indirect calls.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1616973004
Cr-Commit-Position: refs/heads/master@{#33442}
Platforms which do not provide rounding instructions (like x64 without
sse4.1, arm before v8) fall back to this new soft float inplementation.
BUG=575379
LOG=Y
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1611513003
Cr-Commit-Position: refs/heads/master@{#33412}
Reason for revert:
Code is incorrect for -0.
Original issue's description:
> [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1.
>
> The implementation sets the rounding mode flag and then uses the
> cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
> the rounding. Input values outside int range either don't have to be
> rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
> positive inputs, or input -2^52 + 2^52 for negative inputs. The original
> rounding mode is restored afterwards.
>
> R=titzer@chromium.org
>
> B=575379
>
> Committed: https://crrev.com/fa5d09e547abe79a8c82f780deb980c53ad78beb
> Cr-Commit-Position: refs/heads/master@{#33367}
TBR=titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1593313010
Cr-Commit-Position: refs/heads/master@{#33369}
The implementation sets the rounding mode flag and then uses the
cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
the rounding. Input values outside int range either don't have to be
rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
positive inputs, or input -2^52 + 2^52 for negative inputs. The original
rounding mode is restored afterwards.
R=titzer@chromium.org
B=575379
Review URL: https://codereview.chromium.org/1584663007
Cr-Commit-Position: refs/heads/master@{#33367}
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 case to keep the same precision for Run_WasmCall_Float32Sub.
Such as: volatile float expect = *i +/- *j; // *i +/- *j, etc.
BUG=
Review URL: https://codereview.chromium.org/1561023002
Cr-Commit-Position: refs/heads/master@{#33143}
Work around ppc assembler use of Mul, Div macros.
Disable several tests that fail for nosse4.
Disable several tests that fail for msan.
BUG=
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1562513002
Cr-Commit-Position: refs/heads/master@{#33126}
The new implementation detects if the input value is outside i32 range
and traps it that case.
The range check is done as follows:
The input value is converted to int32 and then back to float. If the
result is the same as the truncated input value, then the input value
is within int32 range.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1537393003
Cr-Commit-Position: refs/heads/master@{#32984}
Make WasmModule free it's own memory, avoid mixing stack and
heap allocations in tests. This fixes several memory leaks.
Fix several signed compare issues.
Fix several floating point warnings.
Don't setup heap as external, as then the GC can't collect it.
Disable some tests that fail under ASAN.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1538543002
Cr-Commit-Position: refs/heads/master@{#32948}
The code generation for pushing call parameters on the stack does not
distinguish between float32 and float64 parameters because both are
stored in the same registers. Therefore float32 parameters require two
words on the stack. The wasm linkage, however, only considered one word
on the stack for float32 parameters, which caused the problem that
float32 parameters were not located correctly on the stack. I fixed the
problem by considering two words for float32 parameters on the stack.
R=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1529773003
Cr-Commit-Position: refs/heads/master@{#32893}
The test Run_Wasm_StoreMem_offset_oob contained an I64STORE instruction,
which is not yet implemented on 32 bit platforms. I turned off those
parts of the test on 32 bit platforms which contain I64 instructions.
R=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1526573002
Cr-Commit-Position: refs/heads/master@{#32842}
Before this change traps always returned a 32 bit word in tests. With this
change traps return either a 32 bit word or a64 bit word, depending on the size
of the actual return value of the test.
Additionally this CL implements the wasm instructions I64SCONVERTF32,
I64UCONVERTF32, I64SCONVERTF64, and I64UCONVERTF64.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1519013003
Cr-Commit-Position: refs/heads/master@{#32800}
As discussed in person, this adds the code from v8-native-prototype into
V8 proper, guarded by GYP flags that do not build the code by default.
Passing wasm=on to 'make' or setting v8_wasm as a GYP flag activates
building of this code.
An additional header file is added to and exported from the compiler
directory, src/compiler/wasm-compiler.h. This exposes a limited interface
with opaque Node and Graph types to the decoder to build TF graphs, as
well as functions to compile WASM graphs.
The mjsunit tests added are blacklisted because they fail without the
WASM object exposed to JS, which is also disabled by the build config
option.
This corresponds closely to 5981e06ebc, with some formatting fixes and moving some files into src/compiler.
R=mstarzinger@chromium.org, bradnelson@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1504713014
Cr-Commit-Position: refs/heads/master@{#32794}
