Skip to content

V
V8
Switch branch/tag
  1. 21 Mar, 2017 29 commits
  3. 20 Mar, 2017 11 commits
    • sebmarchand's avatar
      Disable the 'Function marked forceinline not inlined.' warning on Win. · 2470f2ac
      sebmarchand authored 
      This used to be disabled implicitly and started to broke after some
refactoring in https://codereview.chromium.org/2758563002

BUG=chromium:703027

Review-Url: https://codereview.chromium.org/2758423002
Cr-Commit-Position: refs/heads/master@{#43958}
      2470f2ac
    • bmeurer's avatar
      [turbofan] Inline String.prototype.concat with PlainPrimitive parameter. · f08c3fd3
      bmeurer authored 
      When we hit a call to String.prototype.concat builtin, where we can
infer that the receiver is a String and there's exactly one parameter,
which is of type PlainPrimitive, then we can reduce that to a call to
the StringAddStub instead, optionally converting the non-String - but
PlainPrimitive - parameter to a String.

BUG=v8:5267
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2758383002
Cr-Commit-Position: refs/heads/master@{#43957}
      f08c3fd3
    • 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
    • mtrofin's avatar
      [wasm] Transferrable modules · 99743ad4
      mtrofin authored 
      We want to restrict structured cloning in Chrome to:
- postMessage senders and receivers that are co-located
in the same process
- indexedDB (just https).

For context, on the Chrome side, we will achieve the postMessage part
by using a mechanism similar to transferrables: the
SerializedScriptValue will have a list of wasm modules, separate from
the serialized data stream; and this list won't be copied cross
process boundaries. The IDB part is achieved by explicitly opting in
reading/writing to the serialization stream. To block attack vectors
in IPC cases, the default for deserialization will be to expect data
in the wasm transfers list.

This change is the V8 side necessary to enabling this design. We
introduce TransferrableModule, an opaque datatype exposed to the
embedder. Internally, TransferrableModules are just serialized data,
because we don't have a better mechanism, at the moment, for
de-contextualizing/re-contextualizing wasm modules (wrt Isolate and
Context).

The chrome defaults will be implemented in the
serialization/deserialization delegates on that side. For the v8 side
of things, in the absence of a serialization delegate, the V8
serializer will write to serialization stream. In the absence of a
deserialization delegate, the deserializer won't work. This asymmetry
is intentional - it communicates to the embedder the need to make a
policy decision, otherwise wasm serialization/deserialization won't
work "out of the box".

BUG=v8:6079

Review-Url: https://codereview.chromium.org/2748473004
Cr-Commit-Position: refs/heads/master@{#43955}
      99743ad4
    • bjaideep's avatar
      PPC/s390: [wasm] Lazy compilation for asm.js · b1841eec
      bjaideep authored 
      Port 4f3e168c

Original Commit Message:

    This CL adds general lazy compilation support to WebAssembly, according
    to the design described in the design doc (see referenced bug).

    It's not used currently, but I tested locally that all tests succeed if
    I enable it by default.

    With a later CL, we will enable lazy compilation by default for
    validate-asm: https://chromium-review.googlesource.com/451318

R=clemensh@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5991
LOG=N

Review-Url: https://codereview.chromium.org/2761773004
Cr-Commit-Position: refs/heads/master@{#43954}
      b1841eec
    • Clemens Hammacher's avatar
      Revert "[wasm] Enable lazy compilation for asm-wasm pipeline" · 7de5d703
      Clemens Hammacher authored 
      This reverts commit 64a2287e.

Reason for revert: Breaks on arm64 msan, e.g. https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/13972/steps/Check%20-%20extra/logs/asm-wasm-f32. Will investigate tomorrow.

Original change's description:
> [wasm] Enable lazy compilation for asm-wasm pipeline
> 
> The validate-asm flag now implies lazy compilation.
> 
> R=​titzer@chromium.org, ahaas@chromium.org
> BUG=v8:5991
> 
> Change-Id: I00fb5ddbe13440941a3fafd9175cc9a5d182e15a
> Reviewed-on: https://chromium-review.googlesource.com/451318
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43952}

TBR=bradnelson@chromium.org,ahaas@chromium.org,clemensh@chromium.org,hablich@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5991

Change-Id: I8fe8d9268237c7397f6f22cd20ba6f23b9f5785a
Reviewed-on: https://chromium-review.googlesource.com/456506Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43953}
      7de5d703
    • Clemens Hammacher's avatar
      [wasm] Enable lazy compilation for asm-wasm pipeline · 64a2287e
      Clemens Hammacher authored 
      The validate-asm flag now implies lazy compilation.

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

Change-Id: I00fb5ddbe13440941a3fafd9175cc9a5d182e15a
Reviewed-on: https://chromium-review.googlesource.com/451318
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43952}
      64a2287e
    • Franziska Hinkelmann's avatar
      Revert "[ic] Migrate StoreGlobal to data handler" · 9fa2a371
      Franziska Hinkelmann authored 
      This reverts commit ea4346be.

Reason for revert: This causes a crash in a Node.js test (parallel/test-repl-options). I can reproduce the crash locally. At a first glance, it doesn't look like we're doing anything terribly wrong in Node that explains the crash. I'll have a closer lock tomorrow. Feel free to reland if needed, we can always deactivate the test.  

Original change's description:
> [ic] Migrate StoreGlobal to data handler
> 
> BUG=v8:5561
> 
> Change-Id: If4c679c97af199ce1c90d055627186123bc88574
> Reviewed-on: https://chromium-review.googlesource.com/456698
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43944}

TBR=ishell@chromium.org,verwaest@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5561

Change-Id: I790ff9ab45016749fe2f3982045f497a995e282e
Reviewed-on: https://chromium-review.googlesource.com/456505Reviewed-by: 's avatarFranziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43951}
      9fa2a371
    • 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
    • jkummerow's avatar
      [interpreter] Split bytecode generation out of interpreter.cc · 221dec32
      jkummerow authored 
      as InterpreterGenerator. This is in preparation for no longer including
the bytecode handler generation code in the main library.

BUG=v8:6055

Review-Url: https://codereview.chromium.org/2765433003
Cr-Commit-Position: refs/heads/master@{#43949}
      221dec32
    • 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