1. 06 Feb, 2016 1 commit
  2. 05 Feb, 2016 9 commits
    • mbrandy's avatar
      PPC: [fullcode] Change fullcode to compile finally using the token approach. · 69941bca
      mbrandy authored
      Port 334d1794
      
      Original commit message:
      
          This change should unify handling of finally blocks in Turbofan's
          AstGraphBuilder and in full-code. This should enable smooth deoptimization
          from finally blocks.
      
      R=jarin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1669373002
      
      Cr-Commit-Position: refs/heads/master@{#33792}
      69941bca
    • jarin's avatar
      [fullcode] Change fullcode to compile finally using the token approach. · 334d1794
      jarin authored
      This change should unify handling of finally blocks in Turbofan's
      AstGraphBuilder and in full-code. This should enable smooth deoptimization
      from finally blocks.
      
      Review URL: https://codereview.chromium.org/1663323003
      
      Cr-Commit-Position: refs/heads/master@{#33780}
      334d1794
    • mstarzinger's avatar
      [interpreter] Rename HandlerTable::depth field. · badaf79f
      mstarzinger authored
      This makes the field in question more generic by renaming it from the
      previous "depth" to "data". Pure refactoring, no function change.
      
      R=rmcilroy@chromium.org,yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1670983003
      
      Cr-Commit-Position: refs/heads/master@{#33779}
      badaf79f
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
      
      Reason for revert:
      Must revert for now due to chromium api natives issues.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > (RELAND: the problem before was a missing write barrier for adding the code
      > entry to the new closure. It's been addressed with a new macro instruction
      > and test. The only change to this CL is the addition of two calls to
      > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      > And Benedikt reviewed it as well.
      >
      > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
      > Cr-Commit-Position: refs/heads/master@{#33741}
      
      TBR=bmeurer@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/1670813005
      
      Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
    • mvstanton's avatar
      Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of... · 14fa68a3
      mvstanton authored
      Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of https://codereview.chromium.org/1671553002/ )
      
      Reason for revert:
      issues with chromium api natives, must revert for now, thanks.
      
      Original issue's description:
      > PPC: Type Feedback Vector lives in the closure
      >
      > Port bb31db3a
      >
      > Original commit message:
      >     (RELAND: the problem before was a missing write barrier for adding the code
      >     entry to the new closure. It's been addressed with a new macro instruction
      >     and test. The only change to this CL is the addition of two calls to
      >     __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      >     We get less "pollution" of type feedback if we have one vector per native
      >     context, rather than one for the whole system. This CL moves the vector
      >     appropriately.
      >
      >     We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      >     vector actually lives in the first slot of the literals array (indeed there is
      >     great commonality between those arrays, they can be thought of as the same
      >     thing). So we make greater effort to ensure there is a valid literals array
      >     after compilation.
      >
      >     This meant, for performance reasons, that we needed to extend
      >     FastNewClosureStub to support creating closures with literals. And ultimately,
      >     it drove us to move the optimized code map lookup out of FastNewClosureStub
      >     and into the compile lazy builtin.
      >
      >     The heap change is trivial so I TBR Hannes for it...
      >     Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      >     And Benedikt reviewed it as well.
      >
      > R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      > BUG=
      >
      > Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
      > Cr-Commit-Position: refs/heads/master@{#33753}
      
      TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
      # 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/1673623002
      
      Cr-Commit-Position: refs/heads/master@{#33765}
      14fa68a3
    • mvstanton's avatar
      Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of... · 0ff456af
      mvstanton authored
      Revert of X87: Type Feedback Vector lives in the closure. (patchset #1 id:1 of https://codereview.chromium.org/1672643002/ )
      
      Reason for revert:
      Bugs with chromium api natives, must revert for now.
      
      Original issue's description:
      > X87: Type Feedback Vector lives in the closure.
      >
      >   port bb31db3a (r33741)
      >
      >   original commit message:
      >   (RELAND: the problem before was a missing write barrier for adding the code
      >   entry to the new closure. It's been addressed with a new macro instruction
      >   and test. The only change to this CL is the addition of two calls to
      >   __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      >   We get less "pollution" of type feedback if we have one vector per native
      >   context, rather than one for the whole system. This CL moves the vector
      >   appropriately.
      >
      >   We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      >   vector actually lives in the first slot of the literals array (indeed there is
      >   great commonality between those arrays, they can be thought of as the same
      >   thing). So we make greater effort to ensure there is a valid literals array
      >   after compilation.
      >
      >   This meant, for performance reasons, that we needed to extend
      >   FastNewClosureStub to support creating closures with literals. And ultimately,
      >   it drove us to move the optimized code map lookup out of FastNewClosureStub
      >   and into the compile lazy builtin.
      >
      >   The heap change is trivial so I TBR Hannes for it...
      >   Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      >   And Benedikt reviewed it as well.
      >
      > BUG=
      >
      > Committed: https://crrev.com/25bfba9329b93cb8ebefe1446e024005a4227a93
      > Cr-Commit-Position: refs/heads/master@{#33759}
      
      TBR=chunyang.dai@intel.com,weiliang.lin@intel.com,zhengxing.li@intel.com
      # 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/1673613002
      
      Cr-Commit-Position: refs/heads/master@{#33764}
      0ff456af
    • neis's avatar
      [generators] Remove full-codegen implementation of yield*. · 9096aef4
      neis authored
      The recently introduced desugaring of yield* renders this code dead.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1648773003
      
      Cr-Commit-Position: refs/heads/master@{#33762}
      9096aef4
    • zhengxing.li's avatar
      X87: [generators] Implement Generator.prototype.return. · c357a87a
      zhengxing.li authored
        port dbd86408 (r33744)
      
        original commit message:
        Note: This is currently only used by yield*, we still need to support it in
        other places (such as for-of loops).  It can be used manually of course.
      
        (This CL does not touch the full-codegen implementation of yield* because that
        code is already dead.  The yield* desugaring already supports return and doesn't
        need to be touched.)
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1671783002
      
      Cr-Commit-Position: refs/heads/master@{#33760}
      c357a87a
    • zhengxing.li's avatar
      X87: Type Feedback Vector lives in the closure. · 25bfba93
      zhengxing.li authored
        port bb31db3a (r33741)
      
        original commit message:
        (RELAND: the problem before was a missing write barrier for adding the code
        entry to the new closure. It's been addressed with a new macro instruction
        and test. The only change to this CL is the addition of two calls to
        __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
        We get less "pollution" of type feedback if we have one vector per native
        context, rather than one for the whole system. This CL moves the vector
        appropriately.
      
        We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
        vector actually lives in the first slot of the literals array (indeed there is
        great commonality between those arrays, they can be thought of as the same
        thing). So we make greater effort to ensure there is a valid literals array
        after compilation.
      
        This meant, for performance reasons, that we needed to extend
        FastNewClosureStub to support creating closures with literals. And ultimately,
        it drove us to move the optimized code map lookup out of FastNewClosureStub
        and into the compile lazy builtin.
      
        The heap change is trivial so I TBR Hannes for it...
        Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
        And Benedikt reviewed it as well.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1672643002
      
      Cr-Commit-Position: refs/heads/master@{#33759}
      25bfba93
  3. 04 Feb, 2016 5 commits
    • adamk's avatar
      Support computed properties for ES2015 Function.name · 21c045a2
      adamk authored
      Adds a new runtime function, %DefineDataPropertyInLiteral, which
      takes a fifth argument specifying whether the property and value
      are syntactically such that the value is a function (or class)
      literal that should have its name set at runtime.
      
      The new runtime call also allows us to eliminate the now-redundant
      %DefineClassMethod runtime function.
      
      This should get much less ugly once we can desugar the "dynamic"
      part of object literals in the parser (but that work is currently
      blocked on having a performant way of desugaring literals).
      
      BUG=v8:3699, v8:3761
      LOG=n
      
      Review URL: https://codereview.chromium.org/1626423003
      
      Cr-Commit-Position: refs/heads/master@{#33756}
      21c045a2
    • mbrandy's avatar
      PPC: [generators] Implement Generator.prototype.return. · bedb3344
      mbrandy authored
      Port dbd86408
      
      Original commit message:
          Note: This is currently only used by yield*, we still need to support it in
          other places (such as for-of loops).  It can be used manually of course.
      
          (This CL does not touch the full-codegen implementation of yield* because that
          code is already dead.  The yield* desugaring already supports return and doesn't
          need to be touched.)
      
      R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:3566
      LOG=y
      
      Review URL: https://codereview.chromium.org/1664413002
      
      Cr-Commit-Position: refs/heads/master@{#33754}
      bedb3344
    • mbrandy's avatar
      PPC: Type Feedback Vector lives in the closure · 753ad25e
      mbrandy authored
      Port bb31db3a
      
      Original commit message:
          (RELAND: the problem before was a missing write barrier for adding the code
          entry to the new closure. It's been addressed with a new macro instruction
          and test. The only change to this CL is the addition of two calls to
          __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
          We get less "pollution" of type feedback if we have one vector per native
          context, rather than one for the whole system. This CL moves the vector
          appropriately.
      
          We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
          vector actually lives in the first slot of the literals array (indeed there is
          great commonality between those arrays, they can be thought of as the same
          thing). So we make greater effort to ensure there is a valid literals array
          after compilation.
      
          This meant, for performance reasons, that we needed to extend
          FastNewClosureStub to support creating closures with literals. And ultimately,
          it drove us to move the optimized code map lookup out of FastNewClosureStub
          and into the compile lazy builtin.
      
          The heap change is trivial so I TBR Hannes for it...
          Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
          And Benedikt reviewed it as well.
      
      R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1671553002
      
      Cr-Commit-Position: refs/heads/master@{#33753}
      753ad25e
    • neis's avatar
      [generators] Implement Generator.prototype.return. · dbd86408
      neis authored
      Note: This is currently only used by yield*, we still need to support it in
      other places (such as for-of loops).  It can be used manually of course.
      
      (This CL does not touch the full-codegen implementation of yield* because that
      code is already dead.  The yield* desugaring already supports return and doesn't
      need to be touched.)
      
      BUG=v8:3566
      LOG=y
      
      Review URL: https://codereview.chromium.org/1639343005
      
      Cr-Commit-Position: refs/heads/master@{#33744}
      dbd86408
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (RELAND: the problem before was a missing write barrier for adding the code
      entry to the new closure. It's been addressed with a new macro instruction
      and test. The only change to this CL is the addition of two calls to
      __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      And Benedikt reviewed it as well.
      
      TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1668103002
      
      Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
  4. 02 Feb, 2016 1 commit
  5. 01 Feb, 2016 1 commit
    • adamk's avatar
      Remove unnecessary ClassLiteral name member and simplify Function.name handling · 8f89ad74
      adamk authored
      A class's name is its constructor's name, so there's no need to treat it separately,
      either in the parser or in code generation. The main parser use of the name is
      for ES2015 Function.name handling, and this patch also cleans up handling there
      by adding a new IsAnonymousFunctionDefinition() method to Expression (the name
      comes from the spec).
      
      Also removed unused ParserTraits::DefaultConstructor method.
      
      BUG=v8:3699
      LOG=n
      
      Review URL: https://codereview.chromium.org/1647213002
      
      Cr-Commit-Position: refs/heads/master@{#33643}
      8f89ad74
  6. 29 Jan, 2016 4 commits
    • mbrandy's avatar
      PPC: Refactor checks for minus zero. · 21bb9c6a
      mbrandy authored
      R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1650593002
      
      Cr-Commit-Position: refs/heads/master@{#33620}
      21bb9c6a
    • mbrandy's avatar
      PPC: Fix "Implement the function.sent proposal." · ceb2d18d
      mbrandy authored
      StoreP needs a scratch register for unaligned immediate offset.
      
      R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:4700
      LOG=n
      
      Review URL: https://codereview.chromium.org/1644863005
      
      Cr-Commit-Position: refs/heads/master@{#33619}
      ceb2d18d
    • mbrandy's avatar
      PPC: [for-in] Ensure that we learn from deopts within for-in loop bodies. · 0dc1e186
      mbrandy authored
      Port 0637f5f6
      
      Original commit message:
          If we deoptimize from TurboFan or Crankshaft into the body of a for-in
          loop and that for-in mode then switches to slow mode (i.e. has to call
          %ForInFilter), we have to record that feedback, because otherwise we
          might actually OSR into that loop assuming that it's fast mode still,
          or even worse recompile the function later when we call it again w/o
          having rerun the for-in loop in fullcodegen from the beginning (where
          was previously the only place we could learn).
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1644383002
      
      Cr-Commit-Position: refs/heads/master@{#33617}
      0dc1e186
    • bmeurer's avatar
      [for-in] Ensure that we learn from deopts within for-in loop bodies. · 0637f5f6
      bmeurer authored
      If we deoptimize from TurboFan or Crankshaft into the body of a for-in
      loop and that for-in mode then switches to slow mode (i.e. has to call
      %ForInFilter), we have to record that feedback, because otherwise we
      might actually OSR into that loop assuming that it's fast mode still,
      or even worse recompile the function later when we call it again w/o
      having rerun the for-in loop in fullcodegen from the beginning (where
      was previously the only place we could learn).
      
      R=mstarzinger@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1638303008
      
      Cr-Commit-Position: refs/heads/master@{#33612}
      0637f5f6
  7. 28 Jan, 2016 1 commit
  8. 27 Jan, 2016 6 commits
    • mstarzinger's avatar
      [fullcodegen] Cleanup MustCreateObjectLiteralWithRuntime. · d211cf24
      mstarzinger authored
      This cleans up the aforementioned predicate to not rely on the flags
      computed for communication between compiled code and the runtime. The
      underlying predicates of the AST are used directly instead.
      
      R=mvstanton@chromium.org
      
      Review URL: https://codereview.chromium.org/1638353002
      
      Cr-Commit-Position: refs/heads/master@{#33559}
      d211cf24
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
      
      Reason for revert:
      Bug: failing to use write barrier when writing code entry into closure.
      
      Original issue's description:
      > Reland of Type Feedback Vector lives in the closure
      >
      > (Fixed a bug found by nosnap builds.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      > BUG=
      >
      > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
      > Cr-Commit-Position: refs/heads/master@{#33548}
      
      TBR=bmeurer@chromium.org,yangguo@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/1643533003
      
      Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • zhengxing.li's avatar
      X87: [es6] Tail calls support. · 66e2a786
      zhengxing.li authored
        port 6131ab1e (r33509)
      
        original commit message:
        This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
        When debugger is active tail calls are disabled.
      
        Tail calling can be enabled by --harmony-tailcalls flag.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1637163003
      
      Cr-Commit-Position: refs/heads/master@{#33549}
      66e2a786
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (Fixed a bug found by nosnap builds.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1642613002
      
      Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
    • mvstanton's avatar
      ObjectLiterals in full code went to the runtime unnecessarily. · 95cb4e04
      mvstanton authored
      BUG=
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1638333002
      
      Cr-Commit-Position: refs/heads/master@{#33546}
      95cb4e04
    • neis's avatar
      Fix bug where generators got closed prematurely. · 2a0e4225
      neis authored
      In a generator function, the parser rewrites a return statement into a "final"
      yield.  A final yield used to close the generator, which was incorrect because
      the return may occur inside a try-finally clause and so the generator may not
      yet terminate.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1634553002
      
      Cr-Commit-Position: refs/heads/master@{#33537}
      2a0e4225
  9. 26 Jan, 2016 5 commits
    • mbrandy's avatar
      PPC: [es6] Tail calls support. · 95aedaa0
      mbrandy authored
      Port 6131ab1e
      
      Original commit message:
          This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
          When debugger is active tail calls are disabled.
      
          Tail calling can be enabled by --harmony-tailcalls flag.
      
      R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:4698
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1635823003
      
      Cr-Commit-Position: refs/heads/master@{#33524}
      95aedaa0
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # 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/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
    • rmcilroy's avatar
      [Interpreter] Add native function literal support. · befe61fa
      rmcilroy authored
      Adds support for calling native function literals. Moves the logic for building
      the native function's SharedFunctionInfo out of full-codegen into compiler.cc
      to allow it to be shared between fullcodegen and Ignition.
      
      BUG=v8:4686
      LOG=N
      
      Review URL: https://codereview.chromium.org/1635553002
      
      Cr-Commit-Position: refs/heads/master@{#33510}
      befe61fa
    • ishell's avatar
      [es6] Tail calls support. · 6131ab1e
      ishell authored
      This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
      When debugger is active tail calls are disabled.
      
      Tail calling can be enabled by --harmony-tailcalls flag.
      
      BUG=v8:4698
      LOG=Y
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1609893003
      
      Cr-Commit-Position: refs/heads/master@{#33509}
      6131ab1e
  10. 25 Jan, 2016 3 commits
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored
      Cleanup %ForInPrepare runtime entry, and unify common logic with
      %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
      a TupleType to properly type JSForInPrepare and its projections w/o
      special hacks in the Typer. And fix %ForInNext and JSForInNext to be
      consistent with fullcodegen again (after the proxy refactorings last
      quarter).
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1631583002
      
      Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
    • zhengxing.li's avatar
      X87: [stubs] Introduce ToNameStub to implement %_ToName. · f55b66ca
      zhengxing.li authored
        port a0878333(r33460)
      
        original commit message:
        We already had hand-written optimized code for %_ToName in fullcodegen,
        but the optimizing compilers always went to the runtime for %_ToName,
        which is pretty bad for many of our builtins. So this CL moves the
        existing native code to a ToNameStub (similar to the existing
        ToStringStub), and uses the ToNameStub consistently in all compilers to
        actually implement %_ToName.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1622793006
      
      Cr-Commit-Position: refs/heads/master@{#33483}
      f55b66ca
    • bmeurer's avatar
      [turbofan] Switch JSForInPrepare to %ForInPrepare style. · 825ece48
      bmeurer authored
      Now TurboFan always uses the newly introduced %ForInPrepare, no matter
      whether baseline is the interpreter or fullcodegen. For fullcodegen, we
      introduce a new PrepareId bailout point for this purpose.
      
      Drive-by-fix: Avoid the NoObservableSideEffectsScope in Crankshaft and
      use the PrepareId bailout point instead.
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1630523002
      
      Cr-Commit-Position: refs/heads/master@{#33480}
      825ece48
  11. 22 Jan, 2016 2 commits
    • mbrandy's avatar
      PPC: [stubs] Introduce ToNameStub to implement %_ToName. · 12ac11e9
      mbrandy authored
      Port a0878333
      
      Original commit message:
          We already had hand-written optimized code for %_ToName in fullcodegen,
          but the optimizing compilers always went to the runtime for %_ToName,
          which is pretty bad for many of our builtins. So this CL moves the
          existing native code to a ToNameStub (similar to the existing
          ToStringStub), and uses the ToNameStub consistently in all compilers to
          actually implement %_ToName.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1620313004
      
      Cr-Commit-Position: refs/heads/master@{#33476}
      12ac11e9
    • bmeurer's avatar
      [stubs] Introduce ToNameStub to implement %_ToName. · a0878333
      bmeurer authored
      We already had hand-written optimized code for %_ToName in fullcodegen,
      but the optimizing compilers always went to the runtime for %_ToName,
      which is pretty bad for many of our builtins. So this CL moves the
      existing native code to a ToNameStub (similar to the existing
      ToStringStub), and uses the ToNameStub consistently in all compilers to
      actually implement %_ToName.
      
      Review URL: https://codereview.chromium.org/1622493002
      
      Cr-Commit-Position: refs/heads/master@{#33460}
      a0878333
  12. 21 Jan, 2016 2 commits