Skip to content

V
V8
Switch branch/tag
  1. 22 Apr, 2016 3 commits
  3. 21 Apr, 2016 23 commits
  5. 20 Apr, 2016 14 commits
    • adamk's avatar
      More accurately record an end position for default parameters in arrows · e96cbdcd
      adamk authored 
      Our previous over-conservative answer caused us to emit hole checks in
full-codegen when eagerly parsing but not when lazily parsing.

With this patch, we use the positions of the BinaryOperations making up
the parameter list (which are the positions of the commas) to determine
the appropriate "end position" for each parameter's initializer. This means
that we get accurate-enough positions for the initializers in the eager
parsing step to get the same answers for hole-check-elimination that we
will later during ParseLazy.

In the included test case, for example:

  (function() { ((s = 17, y = s) => s)(); } )();
                        ^2     ^1

The old code would generate a hole check when trying to load
|s| for assignment to |y| (because it treated the closing parentheses
pointed to by "^1" as the "initialization position" of |s|).

The new code uses the comma pointed to by "^2" as the initialization
position of |s|. Since that occurs textually before the load of |s|,
full-codegen knows it can avoid the hole check.

BUG=v8:4908
LOG=n

Review URL: https://codereview.chromium.org/1900343002

Cr-Commit-Position: refs/heads/master@{#35678}
      e96cbdcd
    • jyan's avatar
      S390: [turbofan] CodeGenerator: Frame setup refactoring · 2f2b3040
      jyan authored 
      Port 81a1530e

Original commit message:

    Before frame elision, we finalized the frame shape when assembling the
    prologue, which is also when we prepared the frame (saving sp, etc).

    The frame finalization only needs to happen once, and happens to be
    actually a set of idempotent operations. With frame elision, the logic for
    frame finalization was happening every time we constructed the frame.
    Albeit idempotent operations, the code would become hard to maintain.

    This change separates frame shape finalization from frame
    construction. When constructing the CodeGenerator, we finalize the
    frame. Subsequent access is to a const Frame*.

    Also renamed AssemblePrologue to AssembleConstructFrame, as
    suggested in the frame elision CR.

    Separating frame setup gave the opportunity to do away with
    architecture-independent frame aligning (which is something just arm64
    cares about), and also with stack pointer setup (also arm64). Both of
    these happen now at frame finalization on arm64.

R=mtrofin@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review URL: https://codereview.chromium.org/1903403002

Cr-Commit-Position: refs/heads/master@{#35677}
      2f2b3040
    • bryleun's avatar
      S390: Fixed LBR, LGBR, LHR, LGHR instructions in simulator. · 5ce4a69a
      bryleun authored 
      R=joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,jyan@ca.ibm.com

BUG=

Review URL: https://codereview.chromium.org/1905613002

Cr-Commit-Position: refs/heads/master@{#35675}
      5ce4a69a
    • bjaideep's avatar
      PPC: [turbofan] CodeGenerator: Frame setup refactoring · a9cb48bf
      bjaideep authored 
      Port 81a1530e

Original commit message:

    Before frame elision, we finalized the frame shape when assembling the
    prologue, which is also when we prepared the frame (saving sp, etc).

    The frame finalization only needs to happen once, and happens to be
    actually a set of idempotent operations. With frame elision, the logic for
    frame finalization was happening every time we constructed the frame.
    Albeit idempotent operations, the code would become hard to maintain.

    This change separates frame shape finalization from frame
    construction. When constructing the CodeGenerator, we finalize the
    frame. Subsequent access is to a const Frame*.

    Also renamed AssemblePrologue to AssembleConstructFrame, as
    suggested in the frame elision CR.

    Separating frame setup gave the opportunity to do away with
    architecture-independent frame aligning (which is something just arm64
    cares about), and also with stack pointer setup (also arm64). Both of
    these happen now at frame finalization on arm64.

R=mtrofin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review URL: https://codereview.chromium.org/1903343002

Cr-Commit-Position: refs/heads/master@{#35674}
      a9cb48bf
    • jyan's avatar
      S390: Remove all non-function-name uses of CONST_LEGACY · 70d2c1cf
      jyan authored 
      Port 59546149

Original commit message:

    Now that all 'const' declarations are of the ES2015 variety, the only
    use of CONST_LEGACY is for function name bindings in sloppy mode
    named function expressions.

    This patch aims to delete all code meant to handle other cases, which
    mostly had to do with hole initialization/hole checks. Since function
    name bindings are initialized at entry to a function, it's impossible
    to ever observe one in an uninitialized state.

    To simplify the patch further, it removes the `IMPORT` VariableMode,
    as it's not likely to be needed (IMPORT is identical to CONST for
    the purpose of VariableMode).

R=adamk@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review URL: https://codereview.chromium.org/1901423004

Cr-Commit-Position: refs/heads/master@{#35673}
      70d2c1cf
    • jyan's avatar
      S390: [Interpreter] Remove register file register and replace with LoadParentFramePointer. · b2a36b9e
      jyan authored 
      Port 623ad7de

Original commit message:

    Removes the register file machine register from the interpreter and
    replaces it will loads from the parent frame pointer. As part of this
    change the raw operand values for register values changes to enable the
    interpreter to keep using the operand value as the offset from the
    parent frame pointer.

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1910503002

Cr-Commit-Position: refs/heads/master@{#35672}
      b2a36b9e
    • bjaideep's avatar
      PPC: [regexp] do not assume short external strings have a minimum size. · 7d8e279a
      bjaideep authored 
      Port 3518e492

Original commit message:

    Short external strings do not cache the resource data, and may be used
    for compressible strings. The assumptions about their lengths is
    invalid and may lead to oob reads.

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4923,chromium:604897
LOG=N

Review URL: https://codereview.chromium.org/1901593005

Cr-Commit-Position: refs/heads/master@{#35671}
      7d8e279a
    • clemensh's avatar
      [wasm] Throw real Error on wasm trap · b1434ac4
      clemensh authored 
      Before, just a string was thrown, so no stack trace was attached there.
Generated code from wasm does not grow by this change, we just pass a
message id to the respective (new) runtime function.

R=mstarzinger@chromium.org, titzer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1874383002

Cr-Commit-Position: refs/heads/master@{#35664}
      b1434ac4
    • ahaas's avatar
      [wasm] Wasm functions with int64 parameters can now be called from JS. · 965e6bdc
      ahaas authored 
      All wasm spec tests can now be run on ia32.

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1899753004

Cr-Commit-Position: refs/heads/master@{#35663}
      965e6bdc
    • mstarzinger's avatar
      [compiler] Rename "baseline" to "unoptimized" in pipeline. · 2e9920af
      mstarzinger authored 
      This is just a pure renaming because "baseline" will be the code name
for our upcoming middle tier within the compilation pipeline. It makes
sure the name "baseline" remains unused.

R=rmcilroy@chromium.org

Review URL: https://codereview.chromium.org/1904463002

Cr-Commit-Position: refs/heads/master@{#35661}
      2e9920af
    • yangguo's avatar
      [regexp] do not assume short external strings have a minimum size. · 3518e492
      yangguo authored 
      Short external strings do not cache the resource data, and may be used
for compressible strings. The assumptions about their lengths is
invalid and may lead to oob reads.

R=jkummerow@chromium.org
BUG=v8:4923,chromium:604897
LOG=N

Review URL: https://codereview.chromium.org/1901573003

Cr-Commit-Position: refs/heads/master@{#35660}
      3518e492
    • mbrandy's avatar
      PPC: [crankshaft] Address the deoptimization loops of Math.floor, Math.round and Math.ceil. · 4e93ce4f
      mbrandy authored 
      Port 978ad03b

Original commit message:
    Fix and re-enable the flexible representation for Math.floor (which is used to
    implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
    return double results instead of int32, and therefore allows values outside
    the int32 range, especially -0 is now a valid result, which doesn't deopt.

    Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
    extension.

    This addresses all the known deoptimization loops related to Math.round
    in the Kraken benchmark suite, and seems to also address most of the
    deoptimization loops related to Math.floor in the Oort Online benchmark.

    Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
    optimization that caused the initial revert of the feature (for arm64 only
    back then).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:476477,v8:2890,v8:4059
LOG=n

Review URL: https://codereview.chromium.org/1839643007

Cr-Commit-Position: refs/heads/master@{#35659}
      4e93ce4f
    • jyan's avatar
      S390: Change calling convention of CallApiGetterStub to accept the AccessorInfo · aef33eda
      jyan authored 
      Port d2b0a4b7

Original commit message:

    MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>;

R= verwaest@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review URL: https://codereview.chromium.org/1902353002

Cr-Commit-Position: refs/heads/master@{#35658}
      aef33eda
    • jyan's avatar
      S390: [Atomics] Remove Atomics code stubs; use TF ops · fea4ddaa
      jyan authored 
      Port d412cfa2

Original commit message:
    [Atomics] Remove Atomics code stubs; use TF ops

    Reland of (https://codereview.chromium.org/1891033002)

    This is a much cleaner solution, which won't require nearly as much
    architecture-specific code. Thanks bmeurer@!

R=binji@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4614
LOG=N

Review URL: https://codereview.chromium.org/1897373003

Cr-Commit-Position: refs/heads/master@{#35657}
      fea4ddaa