1. 17 Oct, 2018 1 commit
  2. 15 Oct, 2018 1 commit
  3. 12 Oct, 2018 1 commit
  4. 27 Sep, 2018 1 commit
  5. 15 Jun, 2018 1 commit
  6. 18 May, 2018 1 commit
  7. 05 Apr, 2018 1 commit
    • Peter Marshall's avatar
      Reland "[runtime] Remove the construct_stub field of the SFI" · b158bfdc
      Peter Marshall authored
      This is a reland of 63ecddc8
      
      Original change's description:
      > [runtime] Remove the construct_stub field of the SFI
      >
      > Don't dispatch based on the construct_stub field anymore. Rather than
      > read it out and jump to the construct stub, we can switch on the
      > builtin_id.
      >
      > Builtins will always have builtin_id as a Smi, so this signals we need
      > to jump to JSBuiltinsConstructStub. The only exception is for uncompiled
      > functions, which will have kCompileLazy as the builtin_id, but need to
      > jump to the generic stub instead.
      >
      > API function calls will have a FunctionTemplateInfo in the SFI
      > function_data field, and need to go to the builtins stub as well.
      >
      > The final case is everything else, which should go to the generic stub.
      >
      > Bug: v8:7503
      > Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482
      > Reviewed-on: https://chromium-review.googlesource.com/980941
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52345}
      
      TBR=bmeurer@chromium.org
      
      Bug: v8:7503
      Change-Id: Ie46bfb0af173ad7ac8cbdfeed1865e60f3f413f7
      Reviewed-on: https://chromium-review.googlesource.com/997712Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52389}
      b158bfdc
  8. 04 Apr, 2018 3 commits
    • Ross McIlroy's avatar
      [Compiler] Split up Unoptimized/Optimized CompilationInfo and CompilationJobs · 3a0419a6
      Ross McIlroy authored
      With the Ignition + Turbofan pipeline there is very little overlap between the data
      needed for unoptimized compilation and optimized compilation. As a result, it is
      cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and
      OptimizedCompilationInfo.
      
      Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob
      and OptimizedCompilationJob - again there is not much overlap so this seems cleaner.
      
      Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a
      Reviewed-on: https://chromium-review.googlesource.com/995895
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52369}
      3a0419a6
    • Michael Achenbach's avatar
      Revert "[runtime] Remove the construct_stub field of the SFI" · f49a1a67
      Michael Achenbach authored
      This reverts commit 63ecddc8.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20internal%20snapshot/builds/14773
      
      Original change's description:
      > [runtime] Remove the construct_stub field of the SFI
      > 
      > Don't dispatch based on the construct_stub field anymore. Rather than
      > read it out and jump to the construct stub, we can switch on the
      > builtin_id.
      > 
      > Builtins will always have builtin_id as a Smi, so this signals we need
      > to jump to JSBuiltinsConstructStub. The only exception is for uncompiled
      > functions, which will have kCompileLazy as the builtin_id, but need to
      > jump to the generic stub instead.
      > 
      > API function calls will have a FunctionTemplateInfo in the SFI
      > function_data field, and need to go to the builtins stub as well.
      > 
      > The final case is everything else, which should go to the generic stub.
      > 
      > Bug: v8:7503
      > Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482
      > Reviewed-on: https://chromium-review.googlesource.com/980941
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52345}
      
      TBR=petermarshall@chromium.org,leszeks@chromium.org,bmeurer@chromium.org
      
      Change-Id: I2031913ab5a12018ad932f920792aa1f6faa5e22
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7503
      Reviewed-on: https://chromium-review.googlesource.com/995293Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52346}
      f49a1a67
    • Peter Marshall's avatar
      [runtime] Remove the construct_stub field of the SFI · 63ecddc8
      Peter Marshall authored
      Don't dispatch based on the construct_stub field anymore. Rather than
      read it out and jump to the construct stub, we can switch on the
      builtin_id.
      
      Builtins will always have builtin_id as a Smi, so this signals we need
      to jump to JSBuiltinsConstructStub. The only exception is for uncompiled
      functions, which will have kCompileLazy as the builtin_id, but need to
      jump to the generic stub instead.
      
      API function calls will have a FunctionTemplateInfo in the SFI
      function_data field, and need to go to the builtins stub as well.
      
      The final case is everything else, which should go to the generic stub.
      
      Bug: v8:7503
      Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482
      Reviewed-on: https://chromium-review.googlesource.com/980941Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52345}
      63ecddc8
  9. 29 Mar, 2018 1 commit
  10. 23 Mar, 2018 1 commit
  11. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored
      This is preparatory cleanup work for eventually tracking the functions
      (rather than concrete closures) in the CALL_IC, also for builtins like
      the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
      adds a new FeedbackCell type, which is used by JSFunctions consistently
      now to reference the feedback vector (or undefined if not the function
      is not compiled yet or is a native/asm.js function).
      
      This also changes the calling convention for FastNewClosure builtin and
      the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
      instead of the parent FeedbackVector and the slot index. In addition we
      eliminate the now unused %InterpreterNewClosure runtime function.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
      Reviewed-on: https://chromium-review.googlesource.com/928403
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  12. 29 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Unify CanBePrimitive and NeedsConvertReceiver. · 9fb39c6b
      Benedikt Meurer authored
      The two helper functions CanBePrimitive and NeedsConvertReceiver did
      essentially the same, just in a slightly different way, and both weren't
      really robust wrt. to the list of JSConstruct* and JSCreate* operators
      that they were handling. There's now a single helper in the
      NodeProperties and a couple of extra macro lists to keep this list up
      to date more easily.
      
      Drive-by-fix: Also moved the CanBeNullOrUndefined helper to the
      NodeProperties class.
      
      Bug: v8:5267, v8:7109
      Change-Id: Ibbf387040e3f424ee224c53fac15c2b3207b1926
      Reviewed-on: https://chromium-review.googlesource.com/793734Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49695}
      9fb39c6b
  13. 14 Nov, 2017 1 commit
    • Michael Stanton's avatar
      Revert "[TurboFan] Diagnostic code to track down bug in representation selection" · ebe6d7a9
      Michael Stanton authored
      This reverts commit f010b28f.
      
      Reason for revert: Introduces a clusterfuzz issue and CAnary crash
      
      Original change's description:
      > [TurboFan] Diagnostic code to track down bug in representation selection
      > 
      > We need to characterize the types of dead (IrOpcode::kDead) nodes
      > introduced in compilation phases prior to representation selection.
      > Normally, a dead node isn't expected at the start of this phase. The
      > question is, which phase introduced the dead node and failed to
      > deal with it properly?
      > 
      > Bug: chromium:780658
      > Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
      > Reviewed-on: https://chromium-review.googlesource.com/765968
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49328}
      
      TBR=mvstanton@chromium.org,mstarzinger@chromium.org
      
      Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:780658
      Reviewed-on: https://chromium-review.googlesource.com/768747Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49347}
      ebe6d7a9
  14. 13 Nov, 2017 1 commit
  15. 27 Oct, 2017 1 commit
  16. 17 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline Function#bind in more cases. · 594803c9
      Benedikt Meurer authored
      So far the inlining of Function#bind into TurboFan optimized code was
      limited to cases where TurboFan could infer the constant JSFunction that
      was bound. However we can easily extend that to cover JSBoundFunction as
      well, and obviously also take the LOAD_IC feedback if we don't have a
      known JSFunction or JSBoundFunction.
      
      This adds a new operator JSCreateBoundFunction that contains the logic
      for the creation of the bound function object and the arguments.
      
      On the micro-benchmarks we go from
      
        functionBindParameter0: 1239 ms.
        functionBindConstant0: 478 ms.
        functionBindBoundConstant0: 1256 ms.
        functionBindParameter1: 1278 ms.
        functionBindConstant1: 475 ms.
        functionBindBoundConstant1: 1253 ms.
        functionBindParameter2: 1431 ms.
        functionBindConstant2: 616 ms.
        functionBindBoundConstant2: 1437 ms.
      
      to
      
        functionBindParameter0: 462 ms.
        functionBindConstant0: 485 ms.
        functionBindBoundConstant0: 474 ms.
        functionBindParameter1: 478 ms.
        functionBindConstant1: 474 ms.
        functionBindBoundConstant1: 474 ms.
        functionBindParameter2: 617 ms.
        functionBindConstant2: 614 ms.
        functionBindBoundConstant2: 616 ms.
      
      which is a ~2.5x improvement. On the jshint benchmark in the
      web-tooling-benchmark we observe a 2-3% improvement, which corresponds
      to the time we had seen it running in the generic version.
      
      Bug: v8:6936, v8:6946
      Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3
      Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48639}
      594803c9
  17. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  18. 14 Sep, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Lower monomorphic loads during graph building." · 7540e841
      Jaroslav Sevcik authored
      This reverts commit 14b424c3.
      
      Reason for revert: Regresses benchmarks, e.g., Octane/gameboy
      
      Original change's description:
      > [turbofan] Lower monomorphic loads during graph building.
      > 
      > We introduce an explicit LoweringResult data structure. Until this change,
      > the lowering result could be recovered from the node. However, lowering
      > monomorphic loads requires wiring different value and effect, so we need
      > a structure that can express such lowering result.
      > 
      > Bug: v8:6357
      > Change-Id: I92655800890b744d9203a778a1936a8dcd465ed3
      > Reviewed-on: https://chromium-review.googlesource.com/637304
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47992}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org
      
      Change-Id: I2b7db0278c13414e20c94a34d215ed92bd0d412b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6357
      Reviewed-on: https://chromium-review.googlesource.com/667016Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48012}
      7540e841
  19. 13 Sep, 2017 1 commit
  20. 17 Aug, 2017 3 commits
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile" · 73ec5598
      Ross McIlroy authored
      This is a reland of 21da12a9
      Original change's description:
      > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
      > 
      > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
      > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
      > function. The code in compiler.cc is refactored to use this function to compile
      > the SharedFunctionInfo when compiling a JSFunction.
      > 
      > Also does some other cleanup:
      >  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
      >  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
      >    out of FinalizeUnoptimizedCompile.
      > 
      > BUG=v8:6409
      > 
      > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
      > Reviewed-on: https://chromium-review.googlesource.com/613760
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47394}
      
      TBR=yangguo@chromium.org
      TBR=jarin@chromium.org
      
      Bug: v8:6409
      Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
      Reviewed-on: https://chromium-review.googlesource.com/618886Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47399}
      73ec5598
    • Ross McIlroy's avatar
      Revert "[Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile" · 0f40415b
      Ross McIlroy authored
      This reverts commit 21da12a9.
      
      Reason for revert: Failing on arm64 simulator
      
      Original change's description:
      > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
      > 
      > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
      > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
      > function. The code in compiler.cc is refactored to use this function to compile
      > the SharedFunctionInfo when compiling a JSFunction.
      > 
      > Also does some other cleanup:
      >  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
      >  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
      >    out of FinalizeUnoptimizedCompile.
      > 
      > BUG=v8:6409
      > 
      > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
      > Reviewed-on: https://chromium-review.googlesource.com/613760
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47394}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
      
      Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/618687Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47397}
      0f40415b
    • Ross McIlroy's avatar
      [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile · 21da12a9
      Ross McIlroy authored
      Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
      and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
      function. The code in compiler.cc is refactored to use this function to compile
      the SharedFunctionInfo when compiling a JSFunction.
      
      Also does some other cleanup:
       - Removes CompileUnoptimizedFunction and inlines into new Compiler function
       - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
         out of FinalizeUnoptimizedCompile.
      
      BUG=v8:6409
      
      Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
      Reviewed-on: https://chromium-review.googlesource.com/613760
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47394}
      21da12a9
  21. 10 Aug, 2017 1 commit
  22. 09 Aug, 2017 2 commits
  23. 04 Aug, 2017 1 commit
  24. 03 Aug, 2017 1 commit
  25. 01 Aug, 2017 1 commit
    • jgruber's avatar
      Reland "[builtins] Remove Builtins::Name() accessors" · fcaa2c2e
      jgruber authored
      This is a reland of 2f79e035
      Original change's description:
      > [builtins] Remove Builtins::Name() accessors
      > 
      > Instead of auto-generating the Name() convenience accessor, use a macro to
      > avoid wasting code space.
      > 
      >   BUILTIN_CODE(isolate, Name)
      > 
      > expands to
      > 
      >   isolate->builtins()->builtin_handle(Builtins::kName);
      > 
      > This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
      > 
      > Bug: v8:6624
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
      > Reviewed-on: https://chromium-review.googlesource.com/593607
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47010}
      
      TBR=bmeurer@chromium.org,ahaas@chromium.org
      
      Bug: v8:6624
      Change-Id: I4733731e56dc8873ee06c2b36cac1918c0a658b2
      Reviewed-on: https://chromium-review.googlesource.com/594087
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47037}
      fcaa2c2e
  26. 31 Jul, 2017 2 commits
    • Jakob Gruber's avatar
      Revert "[builtins] Remove Builtins::Name() accessors" · 17a26c0b
      Jakob Gruber authored
      This reverts commit 2f79e035.
      
      Reason for revert: Conflicts with successor CL.
      
      Original change's description:
      > [builtins] Remove Builtins::Name() accessors
      > 
      > Instead of auto-generating the Name() convenience accessor, use a macro to
      > avoid wasting code space.
      > 
      >   BUILTIN_CODE(isolate, Name)
      > 
      > expands to
      > 
      >   isolate->builtins()->builtin_handle(Builtins::kName);
      > 
      > This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
      > 
      > Bug: v8:6624
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
      > Reviewed-on: https://chromium-review.googlesource.com/593607
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47010}
      
      TBR=yangguo@chromium.org,ahaas@chromium.org,jgruber@chromium.org,bmeurer@chromium.org
      
      Change-Id: Ia9ef5c755b26c3f4e143d87a7c51033614ea435e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/594048Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47012}
      17a26c0b
    • jgruber's avatar
      [builtins] Remove Builtins::Name() accessors · 2f79e035
      jgruber authored
      Instead of auto-generating the Name() convenience accessor, use a macro to
      avoid wasting code space.
      
        BUILTIN_CODE(isolate, Name)
      
      expands to
      
        isolate->builtins()->builtin_handle(Builtins::kName);
      
      This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
      
      Bug: v8:6624
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
      Reviewed-on: https://chromium-review.googlesource.com/593607Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47010}
      2f79e035
  27. 26 Jul, 2017 1 commit
  28. 21 Jul, 2017 2 commits
    • Ross McIlroy's avatar
      Revert "[Turbofan] Merged the OSR phase into the graph building phase." · 5d0a4327
      Ross McIlroy authored
      This reverts commit 69c8f16d.
      
      Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154
      
      BUG=chromium:747154
      
      Original change's description:
      > [Turbofan] Merged the OSR phase into the graph building phase.
      > 
      > Now the OSR phase is only used when OSRing from the ast graph builder.
      > When OSRing from Turbofan, the implementation is now in the graph
      > building phase, at the beginning of the VisitBytecode function.
      > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      > nor nodes for the possible code of the OSRed function which is before
      > the OSRed loops.
      > 
      > The trimming and reducing of the OSR phase is not done either. This
      > change in the way the way the OSR is done enabled to remove the
      > workaround to the bug mentioned below.
      > 
      > Bug: v8:6112
      > Bug: v8:6518
      > Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      > Reviewed-on: https://chromium-review.googlesource.com/543042
      > Commit-Queue: Alexandre Talon <alexandret@google.com>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46801}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com
      
      Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6112, v8:6518
      Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46817}
      5d0a4327
    • Ross McIlroy's avatar
      [Compiler] Remove SharedFunctionInfo from ParseInfo. · c179400b
      Ross McIlroy authored
      Removes the SharedFunctionInfo field from the ParseInfo structure. Instead
      require a SharedFunctionInfo to be explicitly passed to ParseFunction.
      Also renames GetUnoptimizedCode to CompileUnoptimizedFunction to make it
      clear it should only be called for non-top-level code.
      
      BUG=v8:5203
      
      Change-Id: Ibce016e6a5290c3685f7f0a2f5fb1eb2df2ffc3b
      Reviewed-on: https://chromium-review.googlesource.com/574589
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46814}
      c179400b
  29. 20 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Merged the OSR phase into the graph building phase. · 69c8f16d
      Alexandre Talon authored
      Now the OSR phase is only used when OSRing from the ast graph builder.
      When OSRing from Turbofan, the implementation is now in the graph
      building phase, at the beginning of the VisitBytecode function.
      We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      nor nodes for the possible code of the OSRed function which is before
      the OSRed loops.
      
      The trimming and reducing of the OSR phase is not done either. This
      change in the way the way the OSR is done enabled to remove the
      workaround to the bug mentioned below.
      
      Bug: v8:6112
      Bug: v8:6518
      Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      Reviewed-on: https://chromium-review.googlesource.com/543042
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46801}
      69c8f16d
  30. 13 Jul, 2017 1 commit
  31. 08 Jun, 2017 1 commit
  32. 06 Jun, 2017 1 commit
  33. 31 May, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support · d3371c23
      jgruber authored
      DebugInfo was very closely tied to break point support:
      * It contained only information relevant to break points.
      * It was created and freed by break point implementation.
      * Existence of a DebugInfo on the shared function info implied existence of
        break points.
      
      This CL is a step towards making DebugInfo usable by other debugging
      functionality such as block coverage by decoupling it from break point support,
      which is now only one kind of information stored on the DebugInfo object.
      
      BUG=v8:6000
      
      Review-Url: https://codereview.chromium.org/2909893002
      Cr-Commit-Position: refs/heads/master@{#45640}
      d3371c23