1. 26 Feb, 2016 1 commit
  2. 25 Feb, 2016 1 commit
  3. 24 Feb, 2016 4 commits
  4. 23 Feb, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Implement operand stack depth tracking. · 38915ed7
      mstarzinger authored
      This implements a mechanism to track the exact depth of the operand
      stack in full-codegen for every sub-expression visitation. So far we
      only tracked the depth at statement level, but not at expression level.
      With the introduction of do-expressions it will be possible to construct
      local control flow (i.e. break, continue and friends) that target labels
      at an arbitrary operand stack depth, making this tracking a prerequisite
      for full do-expression support.
      
      R=rossberg@chromium.org,jarin@chromium.org
      BUG=v8:4755,v8:4488
      LOG=n
      
      Review URL: https://codereview.chromium.org/1706283002
      
      Cr-Commit-Position: refs/heads/master@{#34211}
      38915ed7
  5. 22 Feb, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Lift restriction on --debug-code flag. · 0427abf3
      mstarzinger authored
      This removes a restriction from full-codegen that limited the usability
      of the --debug-code flag to only no-snap configurations. The reasoning
      for the restriction would still hold, if we ever put full-codegen code
      into the snapshot, which we don't. Also there already are several places
      in full-codegen that queried the FLAG_debug_code directly, a more
      reliable mechanism will be needed if we snapshot full code.
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1722593002
      
      Cr-Commit-Position: refs/heads/master@{#34189}
      0427abf3
  6. 19 Feb, 2016 2 commits
  7. 17 Feb, 2016 5 commits
  8. 16 Feb, 2016 2 commits
  9. 15 Feb, 2016 3 commits
  10. 12 Feb, 2016 3 commits
    • bmeurer's avatar
      [runtime] Remove obsolete %ObjectEquals runtime entry. · c67262d4
      bmeurer authored
      There are only two uses of %_ObjectEquals left, which should actually
      use strict equality instead, so there's no need to keep this special
      logic at all.
      
      R=mvstanton@chromium.org
      
      Review URL: https://codereview.chromium.org/1692193002
      
      Cr-Commit-Position: refs/heads/master@{#33948}
      c67262d4
    • bmeurer's avatar
      [runtime] Kill %Arguments and %ArgumentsLength. · 98aec4a7
      bmeurer authored
      This removes support for the %Arguments and %ArgumentsLength runtime
      entries and their intrinsic counterparts. If you need variable arguments
      in any builtin, either use (strict) arguments object or rest parameters,
      which are both compositional across inlining (in TurboFan), and not that
      much slower compared to the %_Arguments hackery.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1688163004
      
      Cr-Commit-Position: refs/heads/master@{#33943}
      98aec4a7
    • bmeurer's avatar
      [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · 09d84535
      bmeurer authored
      The FastNewStrictArgumentsStub is very similar to the recently added
      FastNewRestParameterStub, it's actually almost a copy of it, except that
      it doesn't have the fast case we have for the empty rest parameter. This
      patch improves strict arguments in TurboFan and fullcodegen by up to 10x
      compared to the previous version.
      
      Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
      for the in-object properties instead of having them as constants in the
      Heap class.
      
      Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
      interpreter to avoid the runtime call overhead for strict arguments
      and rest parameter creation.
      
      R=jarin@chromium.org
      TBR=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1693513002
      
      Cr-Commit-Position: refs/heads/master@{#33925}
      09d84535
  11. 11 Feb, 2016 2 commits
    • ishell's avatar
      [es6] Further fixing of tail Calls. · e519e6fa
      ishell authored
      1) Update profiling counters in Full codegen.
      2) Call Runtime::kTraceTailCall when tracing is on
      
      test/mjsunit/es6/tail-call-simple.js is disabled for now, because Turbofan does not fully support TCO yet.
      
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1670133002
      
      Cr-Commit-Position: refs/heads/master@{#33886}
      e519e6fa
    • bmeurer's avatar
      [compiler] Sanitize entry points to LookupSlot access. · 4ff159bd
      bmeurer authored
      Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
      %LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
      %StoreLookupSlot_Strict runtime entry points and use them
      appropriately in the various compilers. This way we can
      finally drop the machine operators from the JS graph level
      completely in TurboFan.
      
      Also drop the funky JSLoadDynamic operator from TurboFan,
      which was by now just a small wrapper around the runtime
      call to %LoadLookupSlot.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1683103002
      
      Cr-Commit-Position: refs/heads/master@{#33880}
      4ff159bd
  12. 10 Feb, 2016 1 commit
    • verwaest's avatar
      Mark null and undefined as undetectable, and use it to handle abstract... · 3ce9e808
      verwaest authored
      Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic
      
      Marking as undetectable makes abstract equality of null, undefined, and
      other undetectable objects easier. Supporting it in the generic compare
      IC significantly speeds up dynamic comparison between those values and
      JSReceivers by not falling back to the runtime.
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>
      
      Review URL: https://codereview.chromium.org/1683643002
      
      Cr-Commit-Position: refs/heads/master@{#33858}
      3ce9e808
  13. 09 Feb, 2016 1 commit
    • bmeurer's avatar
      [intrinsics] Kill the %_IsMinusZero intrinsic. · 00f7d1f5
      bmeurer authored
      By now only the default %TypedArray%.prototype.sort compare function
      and the JS implementation of SameValueZero were still using the odd
      %_IsMinusZero intrinsic, whose semantics both included a number check
      (actually HeapNumber test) plus testing if the heap number stores the
      special -0 value. In both cases we already know that we deal with
      number so we can reduce it to a simple number test for -0, which can
      be expressed via dividing 1 by that value and checking the sign of
      the result. In case of the compare function, we can be even smarter
      and work with the reciprocal values in case x and y are equal to 0
      (although long term we should probably rewrite the fast case for
      the typed array sorting function in C++ anyway, which will be way,
      way faster than our handwritten callback-style, type-feedback
      polluted JS implementation).
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1680783002
      
      Cr-Commit-Position: refs/heads/master@{#33833}
      00f7d1f5
  14. 08 Feb, 2016 3 commits
    • mstarzinger's avatar
      Remove --stop-at flag from several backends. · 664110f8
      mstarzinger authored
      The flag in question is a debug-only flag supported by full-codegen and
      Crankshaft only. In it's current form there are some unresolved issues:
      - The flag is defeated by inlining in Crankshaft.
      - The flag is not supported by TurboFan.
      - The flag is not supported by Ignition.
      
      Instead of addressing the above issues and increasing maintenance cost
      for all backends and also given the "slim" test coverage, this CL fully
      removes the support from all backends.
      
      R=bmeurer@chromium.org,jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/1676263002
      
      Cr-Commit-Position: refs/heads/master@{#33817}
      664110f8
    • bmeurer's avatar
      [compiler] Remove the special case "prototype" load in class literals. · 1ffa4547
      bmeurer authored
      This allows us to remove the somewhat awkward BuildLoadObjectField
      from the AstGraphBuilder and also allows us to simplify fullcodegen
      for class literals.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1679813002
      
      Cr-Commit-Position: refs/heads/master@{#33815}
      1ffa4547
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      bmeurer authored
      Replace the somewhat awkward RestParamAccessStub, which would always
      call into the runtime anyway with a proper FastNewRestParameterStub,
      which is basically based on the code that was already there for strict
      arguments object materialization. But for rest parameters we could
      optimize even further (leading to 8-10x improvements for functions with
      rest parameters), by fixing the internal formal parameter count:
      
      Every SharedFunctionInfo has a formal_parameter_count field, which
      specifies the number of formal parameters, and is used to decide whether
      we need to create an arguments adaptor frame when calling a function
      (i.e. if there's a mismatch between the actual and expected parameters).
      Previously the formal_parameter_count included the rest parameter, which
      was sort of unfortunate, as that meant that calling a function with only
      the non-rest parameters still required an arguments adaptor (plus some
      other oddities). Now with this CL we fix, so that we do no longer
      include the rest parameter in that count. Thereby checking for rest
      parameters is very efficient, as we only need to check whether there is
      an arguments adaptor frame, and if not create an empty array, otherwise
      check whether the arguments adaptor frame has more parameters than
      specified by the formal_parameter_count.
      
      The FastNewRestParameterStub is written in a way that it can be directly
      used by Ignition as well, and with some tweaks to the TurboFan backends
      and the CodeStubAssembler, we should be able to rewrite it as
      TurboFanCodeStub in the near future.
      
      Drive-by-fix: Refactor and unify the CreateArgumentsType which was
      different in TurboFan and Ignition; now we have a single enum class
      which is used in both TurboFan and Ignition.
      
      R=jarin@chromium.org, rmcilroy@chromium.org
      TBR=rossberg@chromium.org
      BUG=v8:2159
      LOG=n
      
      Review URL: https://codereview.chromium.org/1676883002
      
      Cr-Commit-Position: refs/heads/master@{#33809}
      3ef573e9
  15. 05 Feb, 2016 3 commits
    • 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
    • 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
    • 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
  16. 04 Feb, 2016 3 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
    • 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
  17. 02 Feb, 2016 1 commit
  18. 29 Jan, 2016 1 commit
    • 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
  19. 28 Jan, 2016 1 commit
  20. 27 Jan, 2016 1 commit
    • 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