Skip to content

V
V8
Switch branch/tag
  1. 26 Oct, 2016 8 commits
    • machenbach's avatar
      [test] Remove verbose output printing on windows. · fa12e775
      machenbach authored 
      The original reason for the extra output on windows is
obsolete since a while. Now the extra output just spams
the logs and causes traffic.

BUG=chromium:485932

Review-Url: https://codereview.chromium.org/2452763003
Cr-Commit-Position: refs/heads/master@{#40580}
      fa12e775
    • neis's avatar
      [runtime] Let native setters have a return value. · f33a4078
      neis authored 
      Native setters (see AccessorInfo in accessors.h) didn't have the ability
to return a result value. As a consequence of this, for instance, Reflect.set
on the length property of arrays had the wrong behavior:

var y = [];
Object.defineProperty(y, 0, {value: 42, configurable: false})
Reflect.set(y, 'length', 0)

The Reflect.set call used to return true. Now it returns false as
required by the spec.

BUG=v8:5401

Review-Url: https://codereview.chromium.org/2397603003
Cr-Commit-Position: refs/heads/master@{#40579}
      f33a4078
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 3aa57eb9
      bmeurer authored 
      For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.

TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.

R=yangguo@chromium.org
BUG=chromium:659475

Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40578}
      3aa57eb9
    • bmeurer's avatar
      [crankshaft] Refactor kAllowUndefinedAsNaN to kTruncatingToNumber. · df981a9f
      bmeurer authored 
      The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.

Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).

This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.

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

Review-Url: https://codereview.chromium.org/2449353002
Cr-Commit-Position: refs/heads/master@{#40577}
      df981a9f
    • cbruni's avatar
      [builtins] Fix Object.create(null) special case · 58e0e3f6
      cbruni authored 
      Fix failing assertions in the CodeStubAssembler that cause Object.create(null,
global) fail.
Drive-by-fix: convert some Assert to CSA_ASSERT.

BUG=chromium:657692

Review-Url: https://codereview.chromium.org/2446203003
Cr-Commit-Position: refs/heads/master@{#40576}
      58e0e3f6
    • cbruni's avatar
      Remove last references to NeanderObject · e408864d
      cbruni authored 
      All uses of NeanderObject have been replaced by FixedArrays.

BUG=

Review-Url: https://codereview.chromium.org/2447123002
Cr-Commit-Position: refs/heads/master@{#40575}
      e408864d
    • cbruni's avatar
      [runtime] Fix Object.create(null) initialization order · f5d4f8f8
      cbruni authored 
      A GC might cause the just created dictionary object to have an invalid backing
store, which breaks heap verification.

BUG=chromium:659088

Review-Url: https://codereview.chromium.org/2452653002
Cr-Commit-Position: refs/heads/master@{#40574}
      f5d4f8f8
    • bmeurer's avatar
      [builtins] Don't canonicalize results of Math double operations. · 9f4f582b
      bmeurer authored 
      For Math builtins that likely yield double results, i.e. Math.sin,
Math.cos and friends, don't bother trying to canonicalize the result
to Smi. The rationale behind this is that other parts of V8 use the
HeapNumber representation as a hint to assume that certain values
should be represented as double (i.e. for the array elements kind
and for double field tracking). This way the chance that we make
the ideal decision early on is better.

For Math.abs we establish the contract that if the input value is a
Smi, then we try hard to return a Smi (doesn't work for minimal Smi
value), otherwise we preserve the HeapNumberness of the input.

Same for the generic Add, Subtract, Multiply, etc. code stubs.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2451973003
Cr-Commit-Position: refs/heads/master@{#40573}
      9f4f582b
  3. 25 Oct, 2016 29 commits
  5. 24 Oct, 2016 3 commits
    • rmcilroy's avatar
      [Interpreter] Optimize the Register Optimizer. · ed7bef5b
      rmcilroy authored 
      Modify the Bytecode Register Optimizer to be an independent component
rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
can explicitly call it with register operands when outputting a bytecode
and the Bytecode Register Optimizer doesn't need to work out which operands
are register operands. This also means we don't need to build BytecodeNodes
for Ldar / Star / Mov bytecodes unless they are actually emitted by the
optimizer.

This change also modifies the way the BytecodeArrayBuilder converts
operands to make use of the OperandTypes specified in bytecodes.h.
This avoids having to individually convert operands to their raw output
value before calling Output(...).

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2393683004
Cr-Commit-Position: refs/heads/master@{#40543}
      ed7bef5b
    • verwaest's avatar
      Simplify and fix the rewriter · caba112d
      verwaest authored 
      Now we
- always set .result to undefined before a visited loop and switch since we can't know whether they will set a value,
- only visit finally if it can break/continue; and only store/restore .result in that case

BUG=

Review-Url: https://codereview.chromium.org/2427253003
Cr-Commit-Position: refs/heads/master@{#40542}
      caba112d
    • rmcilroy's avatar
      Don't call FastNewFunctionContextStub if context is bigger than kMaxRegularHeapObjectSize. · 381b5437
      rmcilroy authored 
      CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub
to take a number of slots parameter and in-doing so removed the maximum slot
count for FastNewFunctionContextStub. This made it possible to create a
closure which is larger than kMaxRegularHeapObjectSize and so can't be
allocated by FastNewFunctionContextStub.

Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much
larger) to ensure we call the runtime for contexts which need to be
allocated in the LO space.

BUG=chromium:655573

Review-Url: https://codereview.chromium.org/2445703002
Cr-Commit-Position: refs/heads/master@{#40541}
      381b5437