1. 04 Jan, 2018 1 commit
  2. 25 Oct, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Prune control flow based on failed map checks and comparisons." · f3b4841d
      Jaroslav Sevcik authored
      This reverts commit 37b4b2f1.
      
      Reason for revert: Likely breaking canary.
      
      Original change's description:
      > [turbofan] Prune control flow based on failed map checks and comparisons.
      > 
      > This introduces unreachable state into load elimination. We mark state
      > as unreachable if we know statically that a map check would fail.
      > When processing effect phis, we disconnect unreachable state's
      > control from the effect phi's merge, and point it to RuntimeAbort.
      > The control input to the merge is then updated with Dead. Dead
      > code elimination prunes the merge, phis and effect phis.
      > 
      > Bug: v8:6396
      > Change-Id: I01874b576e548747a915c7b645b96ebaa6f6700d
      > Reviewed-on: https://chromium-review.googlesource.com/730754
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48810}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6396, chromium:777843
      Change-Id: I6fac6f86e138f33756e688ec30424cb940690dae
      Reviewed-on: https://chromium-review.googlesource.com/737829Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48918}
      f3b4841d
  3. 22 Oct, 2017 1 commit
  4. 19 Oct, 2017 2 commits
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Load elimination prunes control flow based on instance type." · 8f09a751
      Jaroslav Sevcik authored
      This reverts commit 71bcc1d9.
      
      Reason for revert: Regresses Octane/Box2D, among other things.
      
      Original change's description:
      > [turbofan] Load elimination prunes control flow based on instance type.
      > 
      > Changes:
      > - introduce the notion of unreachable abstract states.
      > 
      > - reconnect unreachables states to runtime abort in effect phis (so that
      >   the merged states are not polluted by unreachable branches while
      >   preserving SSA).
      > 
      > - mark states with failed map checks, unreachable map guars as unreachable.
      > 
      > - add instance type to AbstractMaps, only invalidate instance type on
      >   mismatched effect merges.
      > 
      > 
      > This results in 2-3% improvement on ARES/ML steady state.
      > 
      > Bug: v8:6396
      > Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
      > Reviewed-on: https://chromium-review.googlesource.com/727761
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48742}
      
      TBR=jarin@chromium.org,bmeurer@chromium.org
      
      Change-Id: I6302b37dbf5ea781c64815ef1900681531ad7d71
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6396
      Reviewed-on: https://chromium-review.googlesource.com/728440Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48763}
      8f09a751
    • Jaroslav Sevcik's avatar
      [turbofan] Load elimination prunes control flow based on instance type. · 71bcc1d9
      Jaroslav Sevcik authored
      Changes:
      - introduce the notion of unreachable abstract states.
      
      - reconnect unreachables states to runtime abort in effect phis (so that
        the merged states are not polluted by unreachable branches while
        preserving SSA).
      
      - mark states with failed map checks, unreachable map guars as unreachable.
      
      - add instance type to AbstractMaps, only invalidate instance type on
        mismatched effect merges.
      
      
      This results in 2-3% improvement on ARES/ML steady state.
      
      Bug: v8:6396
      Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
      Reviewed-on: https://chromium-review.googlesource.com/727761Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48742}
      71bcc1d9
  5. 13 Oct, 2017 2 commits
  6. 09 Oct, 2017 2 commits
  7. 11 Aug, 2017 1 commit
  8. 02 Aug, 2017 1 commit
  9. 31 Jul, 2017 1 commit
  10. 28 Jul, 2017 1 commit
  11. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback
      vector to store an optimization marker (optimize/in optimization queue)
      rather than changing the JSFunction's code object. Then, adapt the
      self-healing mechanism to also dispatch based on this optimization
      marker. Similarly, replace SFI marking with optimization marker checks
      in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing
      shared function marking) without leaking this information across native
      contexts. Non I+TF functions (asm.js or --no-turbo) use a
      CheckOptimizationMarker shim which generalises the old
      CompileOptimized/InOptimizationQueue builtins and also checks the same
      optimization marker as CompileLazy and InterpreterEntryTrampoline.
      
      This is a reland of https://chromium-review.googlesource.com/c/509716
      
      Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
      Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  12. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored
      This reverts commit e39c9e02.
      
      Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
      
      Original change's description:
      > [compiler] Drive optimizations with feedback vector
      > 
      > For interpreted functions, use the optimized code slot in the feedback vector
      > to store an optimization marker (optimize/in optimization queue) rather than
      > changing the JSFunction's code object. Then, adapt the self-healing mechanism
      > to also dispatch based on this optimization marker. Similarly, replace SFI
      > marking with optimization marker checks in CompileLazy.
      > 
      > This allows JSFunctions to share optimization information (replacing shared
      > function marking) without leaking this information across native contexts. Non
      > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      > generalises the old CompileOptimized/InOptimizationQueue builtins and also
      > checks the same optimization marker as CompileLazy and
      > InterpreterEntryTrampoline.
      > 
      > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      > Reviewed-on: https://chromium-review.googlesource.com/509716
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45901}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      
      Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
      Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback vector
      to store an optimization marker (optimize/in optimization queue) rather than
      changing the JSFunction's code object. Then, adapt the self-healing mechanism
      to also dispatch based on this optimization marker. Similarly, replace SFI
      marking with optimization marker checks in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing shared
      function marking) without leaking this information across native contexts. Non
      I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      generalises the old CompileOptimized/InOptimizationQueue builtins and also
      checks the same optimization marker as CompileLazy and
      InterpreterEntryTrampoline.
      
      Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      Reviewed-on: https://chromium-review.googlesource.com/509716
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  13. 08 Jun, 2017 1 commit
    • bmeurer's avatar
      [builtins] Start refactoring the Apply builtin. · af76779a
      bmeurer authored
      This splits the monolithic Apply builtin into several smaller builtins,
      namely CallVargargs and ConstructVarargs, which accept a length and a
      FixedArray of elements and deal with the actual stack manipulation, and
      CallWithArrayLike / ConstructWithArrayLike that deal with getting the
      elements from the receiver (for Function.prototype.apply, Reflect.apply
      and Reflect.construct), which can now be written using the CSA.
      
      The idea is that these builtins can be reused by TurboFan directly in
      the future when we optimize apply better, and that we can also reuse the
      core logic in the handling of spread calls/constructs.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2930623002
      Cr-Commit-Position: refs/heads/master@{#45794}
      af76779a
  14. 08 May, 2017 1 commit
    • Adam Klein's avatar
      Skip hole initialization of lexical variables when possible · ededfcd2
      Adam Klein authored
      This patch expands scope analysis to skip hole initialization
      when it can be determined statically that no hole checks will
      be generated at runtime.
      
      Two conditions must be met to safely eliminate hole initialization:
        - There must not exist a VariableProxy referencing this Variable
          whose HoleCheckMode is kRequired
        - The Variable must be stack allocated; any other allocation implies
          that it may be accessed from not-yet-analyzed scopes (other modules,
          inner functions, or eval code) and that code may require
          hole checks.
      
      The new logic required removing debug code in full-codegen which is
      now incorrect in some cases.
      
      Also fixed Variable's bitfield helpers to take no more space than needed.
      
      Bug: chromium:651637
      Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
      Reviewed-on: https://chromium-review.googlesource.com/494006
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45170}
      ededfcd2
  15. 21 Apr, 2017 5 commits
  16. 11 Apr, 2017 1 commit
    • gsathya's avatar
      [ESNext] Implement DynamicImportCall · 94283dcf
      gsathya authored
      This patch implements the runtime semantics of dynamic import.
      
      We create a new ASTNode so that we can pass the JSFunction closure() to
      the runtime function from which we get the script_url.
      
      d8 implements the embedder logic required to load and evaluate the modules.
      
      The API is mostly implemented as specified.
      
      BUG=8:5785
      
      Review-Url: https://codereview.chromium.org/2703563002
      Cr-Commit-Position: refs/heads/master@{#44551}
      94283dcf
  17. 22 Mar, 2017 1 commit
  18. 16 Mar, 2017 1 commit
    • jgruber's avatar
      [regexp] Port RegExpExecStub to CSA (mostly) · 5cc61896
      jgruber authored
      This moves most of the logic contained in RegExpExecStub to CSA.  Benefits are
      mostly easier readability and hackability, and removal of a large chunk of
      platform-specific assembly.
      
      Exit frame construction and the final call remain in RegExpExecStub.
      
      BUG=v8:5339,v8:592
      
      Review-Url: https://codereview.chromium.org/2738413002
      Cr-Commit-Position: refs/heads/master@{#43844}
      5cc61896
  19. 15 Mar, 2017 1 commit
  20. 09 Feb, 2017 1 commit
  21. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored
      Previously, when restarting a frame, we would rewrite all frames
      between the debugger activation and the frame to restart to squash
      them, and replace the return address with that of a builtin to
      leave that rewritten frame, and restart the function by calling it.
      
      We now simply remember the frame to drop to, and upon returning
      from the debugger, we check whether to drop the frame, load the
      new FP, and restart the function.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5587
      
      Review-Url: https://codereview.chromium.org/2636913002
      Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  22. 23 Jan, 2017 1 commit
  23. 19 Jan, 2017 1 commit
  24. 18 Jan, 2017 3 commits
  25. 10 Jan, 2017 1 commit
  26. 16 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm. · ca8d3ba7
      ahaas authored
      Original commit message:
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2584603002
      Cr-Commit-Position: refs/heads/master@{#41774}
      ca8d3ba7
  27. 07 Dec, 2016 1 commit
    • caitp's avatar
      [ignition] desugar GetIterator() via bytecode rather than via AST · b5f146a0
      caitp authored
      Introduces:
      - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
      - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
      
      The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
      
      This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have  better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
      
      BUG=v8:4280
      R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org
      TBR=rossberg@chromium.org
      
      Review-Url: https://codereview.chromium.org/2557593004
      Cr-Commit-Position: refs/heads/master@{#41555}
      b5f146a0
  28. 02 Dec, 2016 1 commit
    • bmeurer's avatar
      [compiler] Consistently use Ignition+TurboFan for lexical variables. · 5529430d
      bmeurer authored
      Crankshaft has this highly unpredictable performance cliff around the
      "Unsupported phi use of const or let variable", which is due to the
      fact that Crankshaft refuses to do hole checks (for a couple of
      reasons). So ideally we should not even try to send any lexically bound
      variables to fullcodegen+Crankshaft, but instead give them to Ignition
      and TurboFan.
      
      This CL only adds the appropriate check to the AstNumbering, but doesn't
      remove the functionality from fullcodegen/Crankshaft yet. This would be
      step two in case this CL sticks. If you see any major performance
      regressions with this CL in the range, just revert it and ping me.
      
      See Node.js issue https://github.com/nodejs/node/issues/9729 for
      additional information.
      
      BUG=v8:5666
      R=hablich@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
      
      Review-Url: https://codereview.chromium.org/2525243002
      Cr-Commit-Position: refs/heads/master@{#41445}
      5529430d
  29. 29 Nov, 2016 1 commit
  30. 22 Nov, 2016 1 commit