- 10 May, 2016 1 commit
-
-
titzer authored
[wasm] Introduce special bytecodes for asm.js division/remainder instead of relying on module state. R=ahaas@chromium.org, bradnelson@chromium.org BUG= Review-Url: https://codereview.chromium.org/1968493002 Cr-Commit-Position: refs/heads/master@{#36148}
-
- 09 May, 2016 1 commit
-
-
titzer authored
R=ahaas@chromium.org,rossberg@chromium.org BUG= Review-Url: https://codereview.chromium.org/1960143002 Cr-Commit-Position: refs/heads/master@{#36112}
-
- 03 May, 2016 1 commit
-
-
ahaas authored
Additionally I removed some stale comments. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/1941323002 Cr-Commit-Position: refs/heads/master@{#35976}
-
- 29 Apr, 2016 1 commit
-
-
titzer authored
[wasm] Binary 11: br_table takes a value. [wasm] Binary 11: Add implicit blocks to if arms. [wasm] Binary 11: Add arities to call, return, and breaks [wasm] Binary 11: Add experimental version. This CL changes the encoder, decoder, and tests to use a postorder encoding of the AST, which is more efficient in decode time and space. R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org BUG=chromium:575167 LOG=Y Review-Url: https://codereview.chromium.org/1830663002 Cr-Commit-Position: refs/heads/master@{#35896}
-
- 26 Apr, 2016 1 commit
-
-
clemensh authored
Annotate call nodes in the TF graph with source code information in the form of byte offset relative to the wasm function start. The backend finally outputs those positions as RelocInfo. R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org Review URL: https://codereview.chromium.org/1890803002 Cr-Commit-Position: refs/heads/master@{#35793}
-
- 15 Apr, 2016 2 commits
-
-
ahaas authored
The default NaN mode was originally used to identify holes in double arrays. With (https://codereview.chromium.org/863633002/) signalling NaNs are used for that, and the default NaN mode is not needed anymore. Without the default NaN mode it is easier to satisfy the WebAssembly spec which requires that quiet NaNs are preserved. R=titzer@chromium.org, rodolph.perfetta@arm.com, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1884193003 Cr-Commit-Position: refs/heads/master@{#35526}
-
ahaas authored
The default NaN mode was originally used to identify holes in double arrays. With (https://codereview.chromium.org/863633002/) signalling NaNs are used for that, and the default NaN mode is not needed anymore. Without the default NaN mode it is easier to satisfy the WebAssembly spec which requires that quiet NaNs are preserved. R=titzer@chromium.org, rodolph.perfetta@arm.com, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1884193002 Cr-Commit-Position: refs/heads/master@{#35518}
-
- 04 Apr, 2016 2 commits
-
-
titzer authored
The background here is that graphs generated from WASM are not trimmed. That means there can be some floating control diamonds that are not reachable from end. An assertion in the scheduler for phis from floating diamonds checks that the use edge in this situation is the control edge, but in general, any edge could cause this. Scheduling still works without this assertion. The longer term fix is to either trim the graphs (more compile time overhead for WASM) or improve the scheduler's handling of dead code in the graph. Currently it does not schedule dead code but the potential use positions of dead code are used in the computation of the common dominator of uses. We could recognize dead nodes in PrepareUses() and check in GetBlockForUse() as per TODO. R=bradnelson@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1846933002 Cr-Commit-Position: refs/heads/master@{#35245}
-
ivica.bogosavljevic authored
Run_Wasm_F32CopySign was failing because function copysign that is used to verify the results does implicit conversion from float to double. In this conversion we lose information about NaN sign and the test fails. Fix by using copysignf to avoid unnecessary float to double conversion. TEST=cctest/test-run-wasm/Run_Wasm_F32CopySign BUG= Review URL: https://codereview.chromium.org/1857753002 Cr-Commit-Position: refs/heads/master@{#35237}
-
- 01 Apr, 2016 1 commit
-
-
jochen authored
We expect that the majority of malloc'd memory held by V8 is allocated in Zone objects. Introduce an Allocator class that is used by Zones to manage memory, and allows for querying the current usage. BUG=none R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org LOG=n TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1847543002 Cr-Commit-Position: refs/heads/master@{#35196}
-
- 31 Mar, 2016 2 commits
-
-
ahaas authored
*) For all tests the input validation was incorrect, i.e. some values were considered invalid although they were valid. The problem was that values which are outside int range can get in range through truncation. *) Removed an assertion in the x64 code generation of TruncateFloat64ToUint32 which trapped on negative inputs. *) Introduced a new TF operator TruncateFloat32ToUint32 which does the same as ChangeFloat32ToUint32 but does not trap on negative inputs. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1843983002 Cr-Commit-Position: refs/heads/master@{#35176}
-
titzer authored
R=ahaas@chromium.org, bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1846613002 Cr-Commit-Position: refs/heads/master@{#35156}
-
- 30 Mar, 2016 2 commits
-
-
titzer authored
R=ahaas@chromium.org,bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1845443003 Cr-Commit-Position: refs/heads/master@{#35136}
-
titzer authored
R=ahaas@chromium.org,bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1839333002 Cr-Commit-Position: refs/heads/master@{#35134}
-
- 29 Mar, 2016 1 commit
-
-
titzer authored
In JavaScript code and stubs, JSSP mirrors the CSP but may be unaligned. But in WASM code only CSP is used, like native code, and it must be aligned. Calls into WASM from JS need to carefully align the C stack pointer (csp) and restore the previous JSSP, while calls from WASM to JS need to compute a new JSSP and restore their CSP after the call. R=ahaas@chromium.org BUG= Review URL: https://codereview.chromium.org/1811283003 Cr-Commit-Position: refs/heads/master@{#35096}
-
- 15 Mar, 2016 2 commits
-
-
ahaas authored
Word64Popcnt is lowered to Word32Popcnt(low-word) + Word32Popcnt(high_word). Since the optional Word64Popcnt operator does not exist on 32 bit platforms, I introduced a new operator "Word64PopcntPlaceholder" which is generated in the WasmCompiler and then lowered in the Int64Lowering. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1803453003 Cr-Commit-Position: refs/heads/master@{#34777}
-
ahaas authored
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}
-
- 14 Mar, 2016 2 commits
-
-
titzer authored
Move all tests that use i64 values into test-run-wasm-64.cc. Introduce macros that enable tests as they are implemented on 32 bit platforms. R=ahaas@chromium.org BUG= Review URL: https://codereview.chromium.org/1784343004 Cr-Commit-Position: refs/heads/master@{#34742}
-
ahaas authored
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}
-
- 11 Mar, 2016 1 commit
-
-
ahaas authored
R=binji@chromium.org Review URL: https://codereview.chromium.org/1779123002 Cr-Commit-Position: refs/heads/master@{#34701}
-
- 09 Mar, 2016 1 commit
-
-
titzer authored
R=binji@chromium.org BUG= Review URL: https://codereview.chromium.org/1775123003 Cr-Commit-Position: refs/heads/master@{#34635}
-
- 08 Mar, 2016 1 commit
-
-
binji authored
This CL modifies the following to be LEB128: * Function table indices * Import table signature indices * Export table function indices * Function signature param count * br/br_if break depth * br_table target count * block/loop expression count Still to do: * Import/export names (LEB128 count + inline data) * Data segments (LEB128 offset + size + inline data) * Function header stuff (should seperate into function sig and body sections) * Memory access alignment + offset (still discussing) BUG= R=titzer@chromium.org Review URL: https://codereview.chromium.org/1775873002 Cr-Commit-Position: refs/heads/master@{#34603}
-
- 07 Mar, 2016 2 commits
-
-
titzer authored
Local declarations were previously encoded as an optional set of 4 uint16 values as part of the function declaration. This CL implements the current design of moving these declarations to a list of pairs of (type, count) that is part of the body. R=bradnelson@chromium.org,binji@chromium.org BUG= Review URL: https://codereview.chromium.org/1763433002 Cr-Commit-Position: refs/heads/master@{#34564}
-
ahaas authored
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}
-
- 04 Mar, 2016 5 commits
-
-
titzer authored
R=rossberg@chromium.org,binji@chromium.org,bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1764723002 Cr-Commit-Position: refs/heads/master@{#34511}
-
binji authored
Reland of https://codereview.chromium.org/1765673002 R=titzer@chromium.org R=bradnelson@chromium.org LOG=n BUG= Review URL: https://codereview.chromium.org/1761173003 Cr-Commit-Position: refs/heads/master@{#34506}
-
ahaas authored
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}
-
machenbach authored
Revert of [wasm] Update {i32,i64}.const to use signed leb128 (patchset #3 id:40001 of https://codereview.chromium.org/1765673002/ ) Reason for revert: [Sheriff] Breaks chromium win compile: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/3844/steps/compile/logs/stdio Original issue's description: > [wasm] Update {i32,i64}.const to use signed leb128 > > R=titzer@chromium.org > R=bradnelson@chromium.org > LOG=n > > Committed: https://crrev.com/4b613a67e0aa4e073946f5f0dd95ee9366c8ca86 > Cr-Commit-Position: refs/heads/master@{#34471} TBR=bradnelson@chromium.org,titzer@chromium.org,binji@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/1760363003 Cr-Commit-Position: refs/heads/master@{#34482}
-
binji authored
R=titzer@chromium.org R=bradnelson@chromium.org LOG=n Review URL: https://codereview.chromium.org/1765673002 Cr-Commit-Position: refs/heads/master@{#34471}
-
- 03 Mar, 2016 1 commit
-
-
weiliang.lin authored
BUG= Review URL: https://codereview.chromium.org/1755013003 Cr-Commit-Position: refs/heads/master@{#34455}
-
- 27 Feb, 2016 1 commit
-
-
titzer authored
R=bradnelson@chromium.org,aseemgarg@chromium.org BUG= Review URL: https://codereview.chromium.org/1742073002 Cr-Commit-Position: refs/heads/master@{#34345}
-
- 25 Feb, 2016 1 commit
-
-
ahaas authored
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}
-
- 23 Feb, 2016 1 commit
-
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1716243002 Cr-Commit-Position: refs/heads/master@{#34219}
-
- 18 Feb, 2016 3 commits
-
-
titzer authored
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}
-
ahaas authored
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}
-
ahaas authored
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}
-
- 12 Feb, 2016 1 commit
-
-
titzer authored
R=bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1690343002 Cr-Commit-Position: refs/heads/master@{#33958}
-
- 08 Feb, 2016 1 commit
-
-
binji authored
To bring V8 into line with the proposed design changes in: https://github.com/WebAssembly/design/pull/489 (This CL is forked from https://codereview.chromium.org/1634673002/. That CL doesn't merge cleanly, and I can't update it.) TBR=titzer@chromium.org LOG=Y BUG=chromium:575167 Review URL: https://codereview.chromium.org/1682443002 Cr-Commit-Position: refs/heads/master@{#33828}
-
- 05 Feb, 2016 2 commits
-
-
ahaas authored
To avoid returning a signaling NaN the result is multiplied by 1.0. R=titzer@chromium.org, binji@chromium.org BUG=4733 LOG=Y Review URL: https://codereview.chromium.org/1673583002 Cr-Commit-Position: refs/heads/master@{#33783}
-
titzer authored
To bring V8 into line with the proposed design changes in: https://github.com/WebAssembly/design/pull/489 R=ahaas@chromium.org,bradnelson@chromium.org LOG=Y BUG=chromium:575167 BUG=v8:4735 Review URL: https://codereview.chromium.org/1624323003 Cr-Commit-Position: refs/heads/master@{#33776}
-