1. 21 Apr, 2016 20 commits
  2. 20 Apr, 2016 20 commits
    • rmcilroy's avatar
      [Interpreter] Fix typo in generate-bytecode-expectations. · 04927031
      rmcilroy authored
      BUG=v8:4681
      LOG=N
      
      Review URL: https://codereview.chromium.org/1894073007
      
      Cr-Commit-Position: refs/heads/master@{#35679}
      04927031
    • 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
    • littledan's avatar
      Detach ArrayBuffer in test262 · f32e3024
      littledan authored
      New incoming test262 tests check what happens on detached ("neutered")
      ArrayBuffers. This patch makes the test262 infrastructure define
      detaching an ArrayBuffer in terms of %ArrayBufferNeuter, passing the
      --allow-natives-syntax flag, when it is needed.
      
      BUG=v8:4193
      LOG=N
      R=adamk,machenbach
      
      Review URL: https://codereview.chromium.org/1897203003
      
      Cr-Commit-Position: refs/heads/master@{#35676}
      f32e3024
    • 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
    • machenbach's avatar
      Revert of [wasm] Also test structured stack trace (patchset #4 id:60001 of... · 921381bc
      machenbach authored
      Revert of [wasm] Also test structured stack trace (patchset #4 id:60001 of https://codereview.chromium.org/1875153002/ )
      
      Reason for revert:
      Breaks:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/6322
      
      Original issue's description:
      > [wasm] Also test structured stack trace
      >
      > This extends the wasm test case which only checks the "simple"
      > string-variant of the stack trace.
      > It checks the return values of the getFunctionName, getLineNumber,
      > getFileName and toString methods.
      >
      > R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org
      > BUG=
      
      TBR=ahaas@chromium.org,jfb@chromium.org,titzer@chromium.org,clemensh@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1903293002
      
      Cr-Commit-Position: refs/heads/master@{#35670}
      921381bc
    • clemensh's avatar
      Ignore test failure for today · 0fd76cc2
      clemensh authored
      Fix tomorrow.
      
      BUG=
      TBR=mstarzinger@chromium.org,machenbach@chromium.org
      NOTRY=true
      NOTREECHECKS=true
      
      Review URL: https://codereview.chromium.org/1910493002
      
      Cr-Commit-Position: refs/heads/master@{#35669}
      0fd76cc2
    • rmcilroy's avatar
      Disable InterpreterCreateArguments on nosnap due to issue with --mstackalign flag. · 8fc0e2a7
      rmcilroy authored
      BUG=v8:4928
      LOG=N
      TBR=machenbach@chromium.org
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1902263007
      
      Cr-Commit-Position: refs/heads/master@{#35668}
      8fc0e2a7
    • littledan's avatar
      Pass the --module flag to test262 tests with modules enabled · 8b7b5a6f
      littledan authored
      This causes an incoming test262 test to pass, as part of the next
      test262 roll.
      
      R=adamk,machenbach
      BUG=v8:1569
      LOG=N
      
      Review URL: https://codereview.chromium.org/1896293003
      
      Cr-Commit-Position: refs/heads/master@{#35667}
      8b7b5a6f
    • clemensh's avatar
      [wasm] Also test structured stack trace · 782c204c
      clemensh authored
      This extends the wasm test case which only checks the "simple"
      string-variant of the stack trace.
      It checks the return values of the getFunctionName, getLineNumber,
      getFileName and toString methods.
      
      R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1875153002
      
      Cr-Commit-Position: refs/heads/master@{#35666}
      782c204c
    • clemensh's avatar
      [wasm] Add a cctest for the stack on a wasm trap · ec8e14e6
      clemensh authored
      In contrast to the existing cctest, this time the error is not thrown
      from javascript, but by a trap in wasm. And in contrast to the mjsunit
      tests, this checks the detailed stack trace, not the simple one.
      
      R=jfb@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1884593002
      
      Cr-Commit-Position: refs/heads/master@{#35665}
      ec8e14e6
    • 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
    • thakis's avatar
      32-bit linux: Force 16-byte stack alignment. · 5459468d
      thakis authored
      clang assumes 16-byte stack alignment, but incoming stack alignment isn't
      always guaranteed to be that way.  It looks like v8 was lucky to not hit
      this so far.
      
      See https://crbug.com/418554 -- this makes v8's standalone config match
      Chromium.  See also https://llvm.org/bugs/show_bug.cgi?id=21414
      
      Maybe it's possible to change the caller of OnEntryHook() to guarantee
      the right alignment, but matching Chromium's build flags here seems like
      a good idea in general.
      
      BUG=v8:4928
      LOG=n
      
      Committed: https://crrev.com/3afb3324941625559635380ef98a2ee73e370a0a
      Cr-Commit-Position: refs/heads/master@{#35597}
      
      Review URL: https://codereview.chromium.org/1899783002
      
      Cr-Commit-Position: refs/heads/master@{#35662}
      5459468d
    • 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