Skip to content

V
V8
Switch branch/tag
  1. 10 Jul, 2020 1 commit
  3. 07 Jul, 2020 1 commit
  5. 06 Jul, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add feedback input to remaining operators · aef551aa
      Jakob Gruber authored 
      This is the last batch of operators which used to embed the feedback
vector as a HeapConstant:

- CreateEmptyLiteralArray
- LoadGlobal
- LoadNamed
- StoreDataPropertyInLiteral
- StoreGlobal
- StoreInArrayLiteral
- StoreNamed
- StoreNamedOwn

They now take the vector as an input. In NCI mode, the vector is
loaded from the closure at the beginning of the function.

Bug: v8:8888
Change-Id: Ifd2d2a556db343512b61e099a73702822b1ba9f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282525
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68695}
      aef551aa
  7. 30 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add feedback input to Call nodes · 2b236e33
      Jakob Gruber authored 
      This is likely the major change of the series, as Call nodes are the
focus of call reducer (and to a lesser extent other phases like
inlining).

This CL essentially adds the new input to Call nodes, and updates the
rest of the pipeline. As a (fairly large) drive-by, I also introduce
the JSCallNode wrapper class and apply it in call reducer.

This change, although large, will hopefully make future refactorings
*much* easier, since it is now clear where certain assumptions about
Call node layout are made.

Bug: v8:8888
Change-Id: Ia15fe0ba459b6034863a5815a4e4662cee41fc83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264353
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68616}
      2b236e33
  9. 25 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add feedback input to more nodes kinds · 5d417c0d
      Jakob Gruber authored 
      ... and extend JS node wrapper functionality.

Node wrappers now have accessors for value inputs and
context/control/effect/frame-state inputs. Accessors are typed,
although types aren't very meaningful so far (in current examples we
only distinguish between Object/HeapObject).

The following node kinds now take an additional feedback vector input,
and use the new node wrapper functionality above:

- CloneObject
- CreateLiteralArray
- CreateLiteralObject
- CreateLiteralRegExp
- GetIterator
- GetTemplateObject
- HasProperty
- LoadProperty
- StoreProperty

Bug: v8:8888
Change-Id: I1eb33c078b11725a72ec983bbaa848b9a3c7b0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259936
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68538}
      5d417c0d
  11. 26 May, 2020 1 commit
    • Jakob Gruber's avatar
      [compiler] Clarify ConstructParameters::arity() · 458c07a7
      Jakob Gruber authored 
      ... and CallParameters::arity().

The construct arity contains the actual argument count, plus 2 for the
target  (the first input) and new target (the last input). This CL adds
a named constant and a helper method for accessing arity without extra
args. In the future we may want to remove the extra args from arity()
altogether.

Call arity is similar but includes the target and receiver.

Bug: v8:10542,v8:8888
Change-Id: I850fa314f88c2bee9d4dcd87eac9295b2bf88281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67963}
      458c07a7
  13. 27 Apr, 2020 1 commit
  15. 20 Apr, 2020 1 commit
  17. 08 Apr, 2020 1 commit
  19. 09 Mar, 2020 1 commit
  21. 04 Mar, 2020 1 commit
  23. 29 Jan, 2020 1 commit
    • Jakob Kummerow's avatar
      [turbofan] Repair 'index in typedarray' regression · a35214a0
      Jakob Kummerow authored 
      Bumping the max TypedArray length caused the typer to make different
representation decisions, which caused inefficient back-and-forth
conversions. This patch repairs the microbenchmark where this was
most significant.
There might be additional future work to ensure that TypedArray
accesses that actually use huge indices remain on the fast path as well.

Bug: chromium:1045934
Change-Id: Ic6dccaae35fcdf74a26d47388477a1969bf0aa9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026728
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66026}
      a35214a0
  25. 22 Jan, 2020 1 commit
  27. 09 Jan, 2020 1 commit
  29. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()" · 4671cb56
      Tobias Tebbi authored 
      This reverts commit 91e3243d.

Reason for revert: This deopts to the wrong point.

Original change's description:
> Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
> 
> Current GetIterator bytecode loads and calls @@iterator property on a
> given object. This change extends the bytecode functionality to check
> whether the value returned after calling @@iterator property is a valid
> JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
> returned value is not a valid JSReceiver. This change absorbs the
> functionality of additional two bytecodes - JumpIfJSReceiver and
> CallRuntime, that are part of the iterator protocol in the GetIterator
> bytecode.
> 
> Bug: v8:9489
> Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Cr-Commit-Position: refs/heads/master@{#63704}

TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:9489
Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65541}
      4671cb56
  31. 11 Nov, 2019 2 commits
  33. 07 Nov, 2019 1 commit
  35. 04 Nov, 2019 1 commit
    • Nico Hartmann's avatar
      Preserve feedback and speculation mode for JSCall · 149e4935
      Nico Hartmann authored 
      Changing the target of JSCall nodes (e.g. while lowering higher order calls)
now preserves feedback and speculation mode to allow further (speculative)
optimizations. A flag is introduced to mark feedback unrelated to the call
target after such a transformation. This flag is used to prevent access to
the feedback without the need to invalidate it.

Bug: v8:9702
Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64733}
      149e4935
  37. 17 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      Toon Verwaest authored 
      This is a reland of c7c47c68.

This makes TSAN happy in addition to:

Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.

Bug: v8:9860
Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org

Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}

Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
  39. 16 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      Sathya Gunasekaran authored 
      This reverts commit c7c47c68.

Reason for revert: breaks TSAN
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738

Original change's description:
> Reland "[runtime] Move Context::native_context to the map"
> 
> This is a reland of f05bae1e
> 
> Previously I presumed that the context read from a frame in the profiler was
> a valid context. Turns out that on non-intel we're not guaranteed that the
> frame is properly set up. In the case we looked at, the profiler took a
> sample right before writing the frame marker indicating a builtin frame,
> causing the "context" pointer from that frame to be a bytecode array. Since
> we'll read random garbage on the stack as a possible context pointer, I made
> the code reading the native context from it a little more defensive.
> 
> Bug: v8:9860
> 
> Original change's description:
> > [runtime] Move Context::native_context to the map
> >
> > Remove the native context slot from contexts by making context maps
> > native-context-specific. Now we require 2 loads to go from a context to the
> > native context, but we have 1 field fewer to store when creating contexts.
> >
> > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64296}
> 
> Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64314}

TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com

Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      Toon Verwaest authored 
      This is a reland of f05bae1e

Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.

Bug: v8:9860

Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}

Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64314}
      c7c47c68
  41. 15 Oct, 2019 2 commits
  43. 04 Oct, 2019 1 commit
  45. 30 Sep, 2019 1 commit
  47. 19 Sep, 2019 2 commits
    • Igor Sheludko's avatar
      Reland "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · dc1a93b8
      Igor Sheludko authored 
      This is a reland of 6f9b2bd4

We must load JSTypedArray::base_pointer in TurboFan as tagged value otherwise
this value may become stale pointer after GC.

Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
>
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
>
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}

Bug: v8:9706, chromium:1005599
Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win10-nvidia-rel-64
Change-Id: I7bbd2a439306cdd11f2bb0dab5863498624d9740
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813744Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63898}
      dc1a93b8
    • Clemens Hammacher's avatar
      Revert "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · 815df7d2
      Clemens Hammacher authored 
      This reverts commit 6f9b2bd4.

Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005

Original change's description:
> [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
> 
> On-heap typed arrays contain HeapObject value in |base_pointer| field
> and an offset in |external_pointer| field. When pointer compression is
> enabled we want to combine decompression with the offset addition.
> In order to do that we add an isolate root to the external_pointer value
> and therefore the data pointer computation can is a simple addition of
> a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
> and an |external_pointer| value.
> 
> Bug: v8:9706
> Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63874}

TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org

Change-Id: I901280dd191e78d02969600f775c4f0da796921f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9706
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63886}
      815df7d2
  49. 18 Sep, 2019 1 commit
  51. 16 Sep, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Fix and simplify optimization of access on global proxy · 97c89ebb
      Georg Neis authored 
      We used to have two special cases for named accesses on the global
proxy, one based on seeing the global proxy constant in the graph and
on based on seeing the global proxy map either in the feedback or in
the graph. A change I made a while ago accidentally disabled the second
one. This CL restores that.

Moreover, given how things are set up now (this might have been
different before), the first optimization is subsumed by the second
one, so this CL also removes the first one.

Finally, this CL records an accumulator hint in the case of a load,
which improves precision of the serializer for concurrent inlining.

Tbr: tebbi@chromium.org
Bug: v8:7790
Change-Id: I255afc6c79e5c5c900b3ccfcd8459d836d21e42b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801954
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63806}
      97c89ebb
  53. 13 Sep, 2019 1 commit
  55. 12 Sep, 2019 1 commit
  57. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored 
      This is a reland of 8b89a7c3

Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).


Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  59. 04 Sep, 2019 1 commit
  61. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored 
      This reverts commit 8b89a7c3.

Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272

Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
> 
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
> 
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}

TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com

Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored 
      The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.

Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  63. 30 Aug, 2019 1 commit
  65. 28 Aug, 2019 2 commits
  67. 26 Aug, 2019 1 commit