I turn the test off for now. The problem is that mips does not deal with
signalling NaNs as expected.
@v8-mips-ports: Could it be that the mips simulator deals differently
with signalling NaNs than the actual hardware? The implementation that
is tested in these tests assumes that sNaN * 1.0 = qNaN, where the bits
of sNaN and qNaN are equal except for the most significant mantissa bit.
This assumption holds for the simulator, but seems not to hold for actual
mips hardware. Do you know more about that?
R=mstarzinger@chromium.org, titzer@chromium.org, v8-mips-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1735673003
Cr-Commit-Position: refs/heads/master@{#34278}
This CL introduces an import section that names functions to be imported
as well as a CallImport bytecode to call imports from this table.
R=binji@chromium.org,bradnelson@chromium.org
LOG=Y
BUG=chromium:575167
Review URL: https://codereview.chromium.org/1709653002
Cr-Commit-Position: refs/heads/master@{#34157}
This cleans up and makes the tests easier to write and understand.
Also prepares for adding the WASM interpreter which needs a
different initialization sequence in tests.
R=ahaas@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1707403002
Cr-Commit-Position: refs/heads/master@{#34123}
I extended the Int64Lowering to lower calls, loads, stores, returns, and
parameters and apply the lowering on both the test function TF graph and
the WasmRunner TF graph.
The lowering of calls also requires an adjustment of the call descriptor.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1704033002
Cr-Commit-Position: refs/heads/master@{#34121}
The BufferedRawMachineAssemblerTester caused problems for the
Int64Lowering. Instead we construct a TF graph now which is compiled by
Pipeline::GenerateCodeForTesting.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1702023002
Cr-Commit-Position: refs/heads/master@{#34107}
The goal of the Int64Reducer is to replace all int64 nodes in a tf graph
with a set of int32 nodes such that 64 bit tf functions can be executed
on 32 bit platforms. At the moment the Int64Reducer only replaces
Int64Constants, TruncateInt64ToInt32, and Word64And.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1655883002
Cr-Commit-Position: refs/heads/master@{#33721}
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}
