1. 17 Sep, 2018 1 commit
  2. 14 Sep, 2018 1 commit
  3. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored
      This is a reland of 1c48d52b.
      
      It turned out that IterableToList doesn't always behave according to
      the ES operation with the same name. Specifically, it allows holey arrays
      to take its fast path, which produces an output array with holes where
      actually "undefined" elements should appear.
      
      This CL changes the version of IterableToList that is used for spreads
      (IterableToListWithSymbolLookup) such that holey arrays take the slow path.
      It also includes tests for such situations.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      >
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      >
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      >
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      >
      > Bug: v8:7980
      >
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      Bug: v8:7980
      Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1201882
      Commit-Queue: Hai Dang <dhai@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  4. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored
      This reverts commit 1c48d52b.
      
      Reason for revert: Clusterfuzz found something.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      > 
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      > 
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      > 
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      > 
      > Bug: v8:7980
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
      
      Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7980
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  5. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored
      This CL improves the performance of creating [...a, b] or [...a].
      If the array literal has a leading spread, this CL emits the bytecode
      [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      is implemented by [IterableToListDefault] builtin to create the initial
      array for the leading spread. IterableToListDefault has a fast path to
      clone efficiently if the spread is an actual array.
      
      The bytecode generated is now shorter. Bytecode generation is refactored
      into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      from this optimization also.
      For now, turbofan also lowers the bytecode to the builtin.
      
      The idiomatic use of [...a] to clone the array a now performs better
      than a simple for-loop, but still does not match the performance of slice.
      
      Bug: v8:7980
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  6. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
  7. 21 Jun, 2018 1 commit
  8. 18 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored
      Currently each isolate stores its own array of
      {CallInterfaceDescriptorData}. This array has size 173, and each entry
      has 40 bytes. That's already 7kB per isolate.
      Additionally, each {CallInterfaceDescriptorData} allocates two
      heap-allocated arrays, which probably add up to more than the static
      size of the {CallInterfaceDescriptorData}. Note that all the
      {CallInterfaceDescriptorData} instances are initialized eagerly on
      isolate creation.
      
      Since {CallInterfaceDescriptor} is totally isolate independent itself,
      this CL refactors the current design to avoid a copy of them per
      isolate, and instead shares them process-wide. Still, we need to free
      the allocated heap arrays when the last isolate dies to avoid leaks.
      This can probably be refactored later by statically initializing more
      and avoiding the heap allocations all together.
      
      This refactoring will also allow us to use {CallInterfaceDescriptor}s
      from wasm background compilation threads, which are not bound to any
      isolate.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
      Reviewed-on: https://chromium-review.googlesource.com/1100879
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
    • Leszek Swirski's avatar
      [GetIsolate] Return raw object for bytecode constants · f67e424d
      Leszek Swirski authored
      Return the raw Object* when accessing the constant pool of bytecode
      with the bytecode array accessor, to avoid needing an isolate there.
      If the returned value needs to be a handle, we create the handle
      later.
      
      Bug: v8:7786
      Change-Id: Ifeac2a06f0383230bf7e9bfc1b751d9750ecfb51
      Reviewed-on: https://chromium-review.googlesource.com/1102334
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53784}
      f67e424d
  9. 04 May, 2018 1 commit
  10. 03 May, 2018 1 commit
  11. 02 May, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[parser] Slice the source string where possible" · 18bc2856
      Leszek Swirski authored
      This reverts commit 2df5e7a7.
      
      Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
      
      Original change's description:
      > [parser] Slice the source string where possible
      > 
      > When internalizing string literals (for quoted strings or property names),
      > try to create a sliced string of the source string rather than allocating
      > a copy of the bytes.
      > 
      > This will not work for string literals that contain escapes (e.g. unicode
      > escapes), and currently does not support two-byte strings.
      > 
      > Bug: chromium:818642
      > Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
      > Reviewed-on: https://chromium-review.googlesource.com/1010282
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52898}
      
      TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:818642
      Reviewed-on: https://chromium-review.googlesource.com/1039885
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52919}
      18bc2856
  12. 01 May, 2018 1 commit
  13. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  14. 23 Apr, 2018 1 commit
  15. 20 Apr, 2018 1 commit
  16. 18 Apr, 2018 1 commit
    • Christian O. Andersson's avatar
      [ignition] Optimizing Smi only comparisons · 894b95fe
      Christian O. Andersson authored
      There are various situations where we explicitly compare a SMI against
      another SMI (e.g., BuildIndexedJump). This is also a common pattern for
      generated code (e.g., comparing a loop variable with an integer). Instead
      of using the generic equality/strict-equality stub for this, which is
      expensive, this CL offers a simple comparison stub, repurposing the
      TestEqualStrictNoFeedback bytecode to TestReferenceEqual
      
      Bug: v8:5310
      Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5
      Reviewed-on: https://chromium-review.googlesource.com/1007542Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Christian O. Andersson <cricke@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52655}
      894b95fe
  17. 09 Apr, 2018 1 commit
  18. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  19. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored
      This CL changes the poisoning in the interpreter to use the
      infrastructure used in the JIT.
      
      This does not change the original flag semantics:
      
      --branch-load-poisoning enables JIT mitigations as before.
      
      --untrusted-code-mitigation enables the interpreter mitigations
        (now realized using the compiler back-end), but does not enable
        the back-end based mitigations for the Javascript JIT. So in effect
        --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
        use the same mechanics (including changed register allocation) that
        --branch-load-poisoning enables for the JIT.
      
      Bug: chromium:798964
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
      Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  20. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      [esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
      
      Fixes an error where TemplateLiteral printing in --print-ast
      would try to read an element beyond the length of a vector.
      
      BUG=v8:7415, chromium:820596
      R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
      Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612
  21. 12 Mar, 2018 1 commit
  22. 10 Mar, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[esnext] re-implement template strings" · b8128279
      Michael Achenbach authored
      This reverts commit 8ae19e08.
      
      Reason for revert:
      Speculative revert for layout test:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22215
      
      See:
      https://github.com/v8/v8/wiki/Blink-layout-tests
      
      Original change's description:
      > [esnext] re-implement template strings
      > 
      > - Add a new bytecode for the ToString operation, replacing the old
      > intrinsic call (currently does not collect type feedback).
      > - Add a new AST node to represent TemplateLiterals, and avoid
      > generating unnecessary ToString operations in some simple cases.
      > - Use a single feedback slot for each string addition, because the
      > type feedback should always be the same for each addition
      > 
      > This seems to produce a very slight improvement on JSTests benchmarks
      > and bench-ruben.js from v8:7415, and it's possible that type feedback
      > for the ToString bytecode could provide more opportunities to eliminate
      > the runtime call in TurboFan.
      > 
      > Doesn't touch tagged templates
      > 
      > BUG=v8:7415
      > R=​rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      > 
      > Change-Id: If5a8c68558431f058db894d65776324abf54218e
      > Reviewed-on: https://chromium-review.googlesource.com/945408
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Cr-Commit-Position: refs/heads/master@{#51853}
      
      TBR=rmcilroy@chromium.org,caitp@igalia.com,ishell@chromium.org,bmeurer@chromium.org
      
      Change-Id: Id0529b065493ffc20c8f2b1abacc4c1484c3c046
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7415
      Reviewed-on: https://chromium-review.googlesource.com/958163Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51862}
      b8128279
  23. 09 Mar, 2018 2 commits
    • Caitlin Potter's avatar
      [esnext] re-implement template strings · 8ae19e08
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      BUG=v8:7415
      R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: If5a8c68558431f058db894d65776324abf54218e
      Reviewed-on: https://chromium-review.googlesource.com/945408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51853}
      8ae19e08
    • jgruber's avatar
      Add external references macro list · 3b99189b
      jgruber authored
      The macro list avoids duplication in external-reference-table and will
      allow us to statically determine the size of the table in a follow-up.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I06bb2e8c25970b3c1047dafd6c63d7ca291fe37e
      Reviewed-on: https://chromium-review.googlesource.com/956187
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51850}
      3b99189b
  24. 02 Mar, 2018 1 commit
  25. 27 Feb, 2018 1 commit
  26. 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
  27. 12 Feb, 2018 2 commits
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored
      Moves generation of speculation poison to be based on the PC target vs the
      actual PC being executed. The speculation poison is generated in the prologue
      of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
      The result is stored in a known register, which can then be read using the
      SpeculationPoison machine node.
      
      Currently we need to ensure the SpeculationPoison node is scheduled right after
      the code prologue so that the poison register doesn't get clobbered. This is
      currently not verified, however it's only use is in RawMachineAssembler where
      it is manually scheduled early.
      
      The Ignition bytecode handlers are updated to use this speculation poison
      rather than one generated by comparing the target bytecode.
      
      BUG=chromium:798964
      
      Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
      Reviewed-on: https://chromium-review.googlesource.com/893160
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  28. 29 Jan, 2018 1 commit
  29. 26 Jan, 2018 1 commit
  30. 23 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] Single-switch generator bytecode · c869d40d
      Leszek Swirski authored
      Currently, yields and awaits inside loops compile to bytecode which
      switches to the top of the loop header, and switch again once inside the
      loop. This is to make loops reducible.
      
      This replaces this switching logic with a single switch bytecode that
      directly jumps to the bytecode being resumed. Among other things, this
      allows us to no longer maintain the generator state after the switch at
      the top of the function, and avoid having to track loop suspend counts.
      
      TurboFan still needs to have reducible loops, so we now insert loop
      header switches during bytecode graph building, for suspends that are
      discovered to be inside loops during bytecode analysis. We do, however,
      do some environment magic across loop headers since we know that we will
      continue switching if and only if we reached that loop header via a
      generator resume. This allows us to generate fewer phis and tighten
      liveness.
      
      Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
      Reviewed-on: https://chromium-review.googlesource.com/866734
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50804}
      c869d40d
  31. 22 Jan, 2018 1 commit
  32. 11 Jan, 2018 1 commit
  33. 04 Jan, 2018 1 commit
  34. 14 Dec, 2017 1 commit
  35. 13 Dec, 2017 1 commit
  36. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2