Skip to content

V
V8
Switch branch/tag
  1. 24 Mar, 2017 5 commits
  3. 23 Mar, 2017 7 commits
  5. 22 Mar, 2017 8 commits
  7. 21 Mar, 2017 2 commits
  9. 20 Mar, 2017 9 commits
    • franzih's avatar
      [type profile] Collect return types. · de04df74
      franzih authored 
      Collect type information of return values.

Use *one* feedback slot per function for all its return
statements. For assignments, we currently use
several slots per function, because not all
assignments refer to the same variable.

Instead of the variable names, pass the
source location and print the function name.

Add an integration test for --type-profile that checks
for crashes.

Remove type feedback for assignments for now as it convolutes the output.

************ Function with 2 return statements ********
function testFunction(param, flag) {
  // We want to test 2 different return positions in one function.
  if (flag) {
    var first_var = param;
    return first_var;
  }
  var second_var = param;
  return second_var;
}

testFunction({});
testFunction(123, true);
testFunction('hello');
testFunction(undefined);
*******************************************************

************* Sample Output ***************************
Function: testFunction
424: Object
374: number
424: string
424: undefined
*******************************************************

Missing work:
* Handle fall-off returns
* Collect types for parameters
* Remove duplicates from the list of collected types and use a common base class.

BUG=v8:5935

Review-Url: https://codereview.chromium.org/2755973002
Cr-Commit-Position: refs/heads/master@{#43956}
      de04df74
    • Clemens Hammacher's avatar
      [mjsunit] Fix error message for assertEqualsDelta · bb7fc73d
      Clemens Hammacher authored 
      Before:
Failure: expected <true> found <false>

After:
Failure: expected <0.4 +- 0.001> found <0.3>

R=ahaas@chromium.org

Change-Id: I304fd90112cb7131103863813e7b0920be2b5c04
Reviewed-on: https://chromium-review.googlesource.com/456284Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43950}
      bb7fc73d
    • Clemens Hammacher's avatar
      [wasm] [debug] Add support for global variables · ec37d0b0
      Clemens Hammacher authored 
      When instantiating the wasm interpreter, pass the start address of the
global variables. This was nullptr before, leading to a crash if
debugging a program which accesses globals.
With test.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: I5f419790042ef9a00787df093a07e5e5835d55bd
Reviewed-on: https://chromium-review.googlesource.com/456219
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43948}
      ec37d0b0
    • Clemens Hammacher's avatar
      [wasm] Identify interpreter entry as direct call target · 198bab4e
      Clemens Hammacher authored 
      This fixes a bug where an exported function is being specialized, but
the callsite inside the JS_TO_WASM function was patched to call an
interpreter entry instead. We would not identify the call site as the
one to be patched during specialization, and would thus fail a DCHECK.

R=ahaas@chromium.org
BUG=v8:5822, chromium:702839

Change-Id: I148d98333051c399a4cb11bd9620b396f4eb261d
Reviewed-on: https://chromium-review.googlesource.com/456282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43942}
      198bab4e
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Handle stack unwinding · 91852dff
      Clemens Hammacher authored 
      If an exception is thrown and the wasm interpreter entry frame is
unwound, also the internal frames in the interpreter need to be unwound.
We did not do so before, leaving a corrupted internal state of the wasm
interpreter. Thus reusing it would fail.
This CL fixes this and adds a test which reenters a previously unwound
wasm interpreter. It checks that this works and the correct stack is
returned.
This test also requires support for calling an imported function which
throws, so this change is also included here.

R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822

Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82
Reviewed-on: https://chromium-review.googlesource.com/453938
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43937}
      91852dff
    • Toon Verwaest's avatar
      [ic] Fix 'prototype chain checks' where the holder is the receiver · 6f52dfd7
      Toon Verwaest authored 
      We use LoadFromPrototype also for direct global loads. InitPrototypeChecks did not support this though, and would create a prototype chain check for objects beyond the direct global. This tries to ensure the property on the global itself doesn't exist, which is invalid.

Additionally this CL deletes duplicate code.

BUG=chromium:702798,v8:5561

Change-Id: I318a5b6cd5f7c3efdb3a003e34edd37d5d3f880b
Reviewed-on: https://chromium-review.googlesource.com/457369
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43935}
      6f52dfd7
    • loorongjie's avatar
      Migrate %TypedArray%.prototype.fill to C++ · cb903e31
      loorongjie authored 
      BUG=v8:5929
R=adamk@chromium.org,bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2735563002
Cr-Commit-Position: refs/heads/master@{#43934}
      cb903e31
    • ahaas's avatar
      [wasm][arm] Emit MaybeCheckConstPool in the trap code generation · ab97fd76
      ahaas authored 
      Without the check it happened that the builtin call in the trap code
was too far away from the constant pool and therefore crashed.

BUG=v8:6054
R=bmeurer@chromium.org, v8-arm-ports@googlegroups.com

Review-Url: https://codereview.chromium.org/2738683003
Cr-Commit-Position: refs/heads/master@{#43928}
      ab97fd76
    • bmeurer's avatar
      [turbofan] Properly handle IfException projections on JSForInNext. · a93e5221
      bmeurer authored 
      Don't ignore IfException (and IfSuccess) projections on JSForInNext
nodes during JSTypedLowering::ReduceJSForInNext, but instead rewrire
the IfException projection to the ForInFilter stub call, which can
throw exceptions in case of proxies.

R=yangguo@chromium.org
BUG=v8:6121

Review-Url: https://codereview.chromium.org/2761703002
Cr-Commit-Position: refs/heads/master@{#43925}
      a93e5221
  11. 18 Mar, 2017 1 commit
  13. 17 Mar, 2017 2 commits
    • Marja Hölttä's avatar
      [parser|cleanup] Add tests for duplicate parameters. · ab4233e3
      Marja Hölttä authored 
      There are at least 3 mechanisms for detecting duplicate parameters.
- ExpressionClassifier
- Scope::DeclareParameter checking IsDeclaredParameter
- PatternRewriter::VisitVariableProxy failing to declare a duplicate parameter

The conditions for when duplicate parameters are allowed and when not are pretty
involved too. They are allowed when
- the function is not an arrow function and not a concise method *and*
- when the parameter list is simple *and*
- we're in sloppy mode (incl. the function doesn't declare itself strict).

In addition, we don't recognize some of the early errors, and it's 
non-trivial to see which ones are recognized and which not (see bug
v8:6108). E.g., (dup, dup) => {}; is recognized but (dup, [dup]) => {} is
not. And (dup, [dup]) => 1; is.

We do have tests for some aspects of duplicate parameters (e.g., arrow function
duplicate parameters are included in arrow function tests), but it's hard to see
whether all combinations of the relevant conditions are tested.

This CL adds more structured tests which hopefully enables reducing the
duplicate parameter detection mechanisms to 2 or maybe even to 1.

BUG=v8:6092

Change-Id: Idd3db43b380aae4b9a89be5f1ed0755d39bfb36d
Reviewed-on: https://chromium-review.googlesource.com/456336
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43895}
      ab4233e3
    • Andreas Haas's avatar
      [wasm] Remove the WasmTrapHelper · 87354ade
      Andreas Haas authored 
      Since TrapIf has been implemented on all platforms, there is no need
anymore for the old WasmTrapHelper code. This CL also removes
TrapIf-specific tests.

R=titzer@chromium.org, clemensh@chromium.org

Change-Id: Ic069598441b7bd63bde2e66f4e536abea5ecebe6
Reviewed-on: https://chromium-review.googlesource.com/452380
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43887}
      87354ade
  15. 16 Mar, 2017 5 commits
    • titzer's avatar
      [testing] Add the notion of a wait count to allow tests to robustly wait on asynchronous tasks. · 3bbd81af
      titzer authored 
      Note that this also modifies mjsunit.js to allow the {failWithMessage} method to be monkey-patched by a test. This is necessary because assertions which fail in a promise's then-clause would normally only throw an exception, which is swallowed by the promise, causing the test to silently pass. Instead, patching this {failWithMessage} functionality allows then clauses to use the full assertion machinery of mjsunit.js.

R=ulan@chromium.org, gsathya@chromium.org

BUG=

Review-Url: https://codereview.chromium.org/2752043002
Cr-Commit-Position: refs/heads/master@{#43875}
      3bbd81af
    • cwhan.tunz's avatar
      [typedarrays] Implement %TypedArray%.prototype.lastIndexOf in C++ · da1bddcd
      cwhan.tunz authored 
      - Implement C++ builtins and ElementsAccessor for
  %TypedArray%.prototype.lastIndexOf
- Remove TypedArrayLastIndexOf in src/js/typedarray.js
- Combine InnerArrayLastIndexOf and ArrayLastIndexOf in src/js/array.js

BUG=v8:5929

Review-Url: https://codereview.chromium.org/2744283002
Cr-Commit-Position: refs/heads/master@{#43870}
      da1bddcd
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Throw exception on trap · 783f68c5
      Clemens Hammacher authored 
      This behaviour was missing before. If a trap is encountered in the
interpreter, we now throw the right error. With test.

R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822

Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2
Reviewed-on: https://chromium-review.googlesource.com/453839
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43859}
      783f68c5
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement calling imported functions · f3aeb762
      Clemens Hammacher authored 
      When instantiating the wasm interpreter for debugging, we unwrap all
wasm-to-js wrappers and store the callable objects. The handles are
stored in a DeferredHandleScope and deleted when the InterpreterHandle
(store in WasmDebugInfo) is freed.
A call to an imported function reads the arguments from the stack,
converts them to JS objects, calls the callable, converts back the
return value and pushes it onto the stack.
Reentering the interpreter from the calles JS code is not permitted
yet, but will be in a follow-up CL.
Also, indirect calls to imported functions will have to follow.

R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822

Change-Id: I66c35053bccb6cf8d416606e4f840d888ccb3b65
Reviewed-on: https://chromium-review.googlesource.com/453838
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43855}
      f3aeb762
    • bmeurer's avatar
      [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf. · 9224d5d1
      bmeurer authored 
      The fast-path for Array.prototype.indexOf first checks whether the
receiver is a fast-mode JSArray (and there are no elements in the
prototype chain in case of holey arrays), then loads the known
JSArray::length, and afterwards calls ToInteger on the fromIndex.

But this ToInteger(fromIndex) call can cause arbitrary side effects if
the fromIndex is a JSReceiver, in particular it can invalidate the
assumptions about the fast-mode of the receiver and the length. In the
worst case this leads to OOB memory access.

Quick-fix is to bailout to the runtime if the fromIndex is neither a Smi
nor undefined, which represents the common cases.

R=jarin@chromium.org
BUG=chromium:702058

Review-Url: https://codereview.chromium.org/2756663002
Cr-Commit-Position: refs/heads/master@{#43843}
      9224d5d1
  17. 15 Mar, 2017 1 commit