Skip to content

V
V8
Switch branch/tag
  1. 26 Oct, 2016 6 commits
    • 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 5 commits