Skip to content

V
V8
Switch branch/tag
  1. 16 Sep, 2019 3 commits
    • Suraj Sharma's avatar
      Handle IC Store slow on GlobalObjects · 71ebd28d
      Suraj Sharma authored 
      The new Smi handler created to handle StoreIC_Slow and
KeyedStoreIC_Slow can get incorrectly assigned to global Objects.
Added an extra Check to avoid that.

Bug: chromium:1002628
Change-Id: I370e617e791792c98fa7b0cbf89ee7458f4e4c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803659Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63813}
      71ebd28d
    • Bruce Dawson's avatar
      Speculative fix to crashes from a CPU bug · 10360127
      Bruce Dawson authored 
      For the last few months Chrome has been seeing many "impossible" crashes
on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes
only happen with 64-bit Chrome and only happen in the prologue of two
functions. The crashes come and go across different Chrome versions.
Analysis of most of the crashes shows that the address of the crashing
instruction follows some patterns:

When crashing in GetFieldIndex() the last byte of the address is always
1c, 5c, 9c, or dc.

When crashing in UpdateCaches (fewer unique samples) the last byte of
the address is always 5d or 9d.

The address of the function is 0xc or 0xd bytes earlier so the crashing
functions always start with an address that ends in 10, 50, 90, or d0.

Those addresses are for the crashes on a load of the __security_cookie.
The crashes also occasionally happen on the two instructions that follow
the __security_cookie load in which case the crashing instruction's
address has been seen to end with 23 or a3. This corresponds to a
function start address of 10 or 90.

Since the crash involves reading incorrect instruction bytes when
crossing a 16-byte boundary and since the crash appears to only happen
with particular 16-byte alignments it seems reasonable to force the
function's alignments to a multiple of 32 to see if this reliably
avoids the crashes. This change uses the gcc/clang __attribute__
directive to force 32-byte alignment. I have tested this change enough to
verify that it triggers the desired alignment (with up to 31 "int 3"
instructions added for padding) but since I have never reproduced this
crash I have no way of testing its efficacy.

Bug: chromium:968683, chromium:964273
Change-Id: Ia6e1c6d1e044b84d274817374b25523303e78b51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803775Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63804}
      10360127
    • Ross McIlroy's avatar
      [CSA][cleanup] TNodify builtins-object-gen · ba9775fd
      Ross McIlroy authored 
      Also TNodify:
 - LoadJSPrimitiveWrapperValue
 - GetSuperConstructor
 - InstanceOf

BUG=v8:6949,v8:9396

Change-Id: I4b39b418cdf01bd72e35441f037d16ede9c89ce9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803639
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63791}
      ba9775fd
  3. 13 Sep, 2019 4 commits
  5. 12 Sep, 2019 2 commits
  7. 11 Sep, 2019 1 commit
  9. 10 Sep, 2019 4 commits
  11. 09 Sep, 2019 1 commit
  13. 05 Sep, 2019 1 commit
    • Leszek Swirski's avatar
      Reland^2 "[ic] In-place Double -> Tagged transitions"" · 470e6857
      Leszek Swirski authored 
      This is a reland of 981aafaf

It adds double checks to LoadFieldByIndex in the optimizing compiler, which
are likely the source of the crashes.

Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a.
> This is a reland of 7e1fbe8f.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}

TBR=verwaest@chromium.org

Bug: v8:9606
Bug: chromium:997989
Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63582}
      470e6857
  15. 04 Sep, 2019 2 commits
    • Tobias Tebbi's avatar
      Revert "[compiler] improve inlining heuristics: call frequency per executed bytecodes" · eb443e1f
      Tobias Tebbi authored 
      This reverts commit 352a154e.

Reason for revert: https://crbug.com/999972

Original change's description:
> [compiler] improve inlining heuristics: call frequency per executed bytecodes
> 
> TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
> compile time including off-thread, while improving Octane scores by ~2%.
> 
> How things used to work:
> 
> There is a flag FLAG_min_inlining_frequency that limits inlining by
> the callsite being sufficiently frequently executed. This call frequency
> was measured relative to invocations of the parent (= the function we
> originally optimize). At the same time, the limit was very low (0.15),
> meaning we mostly relied on the total amount of inlined code
> (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
> 
> How things work now:
> 
> Instead of measuring call frequency relative to parent invocations, we
> should have a measure that predicts how often the callsite in question
> will be executed in the future. An obvious attempt at that would be to
> measure how often the callsite was executed in absolute numbers in the
> past. But depending on how fast feedback stabilizes, it can take more
> or less time until we optimize a function. If we just take the absolute
> call frequency up to the point in time when we optimize, we would
> inline more for functions that stabilize slowly, which doesn't make
> sense. So instead, we measure absolute call count per KB of executed
> bytecodes of the parent function.
> Since inlining big functions is more expensive, this threshold is
> additionally scaled linearly with the bytecode-size of the inlinee.
> The resulting formula is:
> call_frequency >
> FLAG_min_inlining_frequency *
>   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
>   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
> 
> The new threshold is chosen in a way that it effectively limits
> inlining, which allows us to increase
> FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
> in general.
> 
> The reduction in compile time (x64 build) of ~10% was observed in Octane,
> ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
> The hope is that this will reduce CPU-time in real-world situations
> too.
> The Octane improvements come from inlining more in places where it
> matters.
> 
> Bug: v8:6682
> 
> Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63449}

TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org

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

Bug: v8:6682 chromium:999972
Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63554}
      eb443e1f
    • Leszek Swirski's avatar
      Revert "Reland "[ic] In-place Double -> Tagged transitions"" · b293533e
      Leszek Swirski authored 
      This reverts commit 981aafaf.

Reason for revert: Still crashing on Canary.

Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a.
> This is a reland of 7e1fbe8f.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}

TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org

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

Bug: v8:9606
Bug: chromium:997989
Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63550}
      b293533e
  17. 02 Sep, 2019 1 commit
  19. 30 Aug, 2019 3 commits
  21. 29 Aug, 2019 4 commits
    • Adam Klein's avatar
      Revert "[destructuring] Elide coercible check for simple keys" · 28fa4cb4
      Adam Klein authored 
      This reverts commit 1fba0441.

Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347

Original change's description:
> [destructuring] Elide coercible check for simple keys
> 
> Simple object destructuring, such as `let {a,b} = o`, is less efficient
> than the equivalent assignments `let a = o.a; let b = o.b`. This is
> because it does a nil check of `o` before the assignments. However, this
> nil check is not strictly necessary for simple (i.e. non-computed) names,
> as there will be an equivalent nil check on the first access to o in
> `o.a`. For computed names the computation is unfortunately obervable.
> 
> So, we can elide the nil check when the first property (if any) of the
> destructuring target is a non-computed name. This messes a bit with our
> error messages, so we re-use the CallPrinter to also find destructuring
> assignment based errors, and fiddle with the error message there. As
> a side-effect, we also get out the object name in the AST, so we can
> output a slightly nicer error message.
> 
> Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63453}

TBR=leszeks@chromium.org,verwaest@chromium.org

Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63465}
      28fa4cb4
    • Leszek Swirski's avatar
      [destructuring] Elide coercible check for simple keys · 1fba0441
      Leszek Swirski authored 
      Simple object destructuring, such as `let {a,b} = o`, is less efficient
than the equivalent assignments `let a = o.a; let b = o.b`. This is
because it does a nil check of `o` before the assignments. However, this
nil check is not strictly necessary for simple (i.e. non-computed) names,
as there will be an equivalent nil check on the first access to o in
`o.a`. For computed names the computation is unfortunately obervable.

So, we can elide the nil check when the first property (if any) of the
destructuring target is a non-computed name. This messes a bit with our
error messages, so we re-use the CallPrinter to also find destructuring
assignment based errors, and fiddle with the error message there. As
a side-effect, we also get out the object name in the AST, so we can
output a slightly nicer error message.

Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63453}
      1fba0441
    • Tobias Tebbi's avatar
      [compiler] improve inlining heuristics: call frequency per executed bytecodes · 352a154e
      Tobias Tebbi authored 
      TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
compile time including off-thread, while improving Octane scores by ~2%.

How things used to work:

There is a flag FLAG_min_inlining_frequency that limits inlining by
the callsite being sufficiently frequently executed. This call frequency
was measured relative to invocations of the parent (= the function we
originally optimize). At the same time, the limit was very low (0.15),
meaning we mostly relied on the total amount of inlined code
(FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.

How things work now:

Instead of measuring call frequency relative to parent invocations, we
should have a measure that predicts how often the callsite in question
will be executed in the future. An obvious attempt at that would be to
measure how often the callsite was executed in absolute numbers in the
past. But depending on how fast feedback stabilizes, it can take more
or less time until we optimize a function. If we just take the absolute
call frequency up to the point in time when we optimize, we would
inline more for functions that stabilize slowly, which doesn't make
sense. So instead, we measure absolute call count per KB of executed
bytecodes of the parent function.
Since inlining big functions is more expensive, this threshold is
additionally scaled linearly with the bytecode-size of the inlinee.
The resulting formula is:
call_frequency >
FLAG_min_inlining_frequency *
  (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
  (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)

The new threshold is chosen in a way that it effectively limits
inlining, which allows us to increase
FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
in general.

The reduction in compile time (x64 build) of ~10% was observed in Octane,
ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
The hope is that this will reduce CPU-time in real-world situations
too.
The Octane improvements come from inlining more in places where it
matters.

Bug: v8:6682

Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63449}
      352a154e
    • Leszek Swirski's avatar
      Revert "[ic] In-place Double -> Tagged transitions" · e39c7019
      Leszek Swirski authored 
      This reverts commit 0736599a.
This reverts commit 7e1fbe8f.

Reason for revert: Still some crashes, reverting to unblock dev.

TBR=ishell@chromium.org,tebbi@chromium.org

Bug: v8:9606
Bug: chromium:997485
Bug: chromium:997989
Change-Id: I9a0cb5440bf4fce06c9e6134dacf5c03d512f049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63441}
      e39c7019
  23. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored 
      Currently the backing store and elements kind might not aligned aka
backing store can be dictionary where elements kind is frozen/sealed
element kinds or the other way around. The reason is that
Object.preventExtensions change elements kind to DICTIONARY while
Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
Apply both these operations can lead to that problem as in
chromium:992914

To solve this issue, we avoid Object.preventExtensions to change backing
store to dictionary by introducing new nonextensible elements kind.
These new nonextensible elements kind are handled similar to frozen,
sealed element kinds. This change not only fixes the problem but also
optimize the performance of nonextensible objects.

Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
Bug: chromium:992914, v8:6831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  25. 27 Aug, 2019 1 commit
  27. 26 Aug, 2019 2 commits
  29. 23 Aug, 2019 2 commits
  31. 22 Aug, 2019 3 commits
  33. 20 Aug, 2019 2 commits
  35. 19 Aug, 2019 2 commits
    • Santiago Aboy Solanes's avatar
      Reland "[CSA][cleanup] TNodify some methods related to prototype and property lookup" · 007cbd2c
      Santiago Aboy Solanes authored 
      This is a reland of 82111e22

Relanding since we now have more shards:
https://chromium-review.googlesource.com/c/v8/v8/+/1760810

Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
>
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
>
> TNodified:
>  * LoadJSFunctionPrototype
>  * TryPrototypeChainLookup
>  * OrdinaryHasInstance
>
> Also TNodified loads regarding:
>  * FeedbackCell::kValueOffset
>  * HeapObject::kMapOffset
>  * JSFunction::kSharedFunctionInfoOffset
>  * JSFunction::kFeedbackCellOffset
>  * Map::kInstanceTypeOffset
>  * Map::kInstanceDescriptorsOffset
>  * Map::kPrototypeOffset
>
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
>
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}

Bug: v8:6949, v8:9396
Change-Id: I040aefcf8af60611f7b3c24f3bd5c661e03b6ada
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760811Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63249}
      007cbd2c
    • Maya Lekova's avatar
      Revert "[CSA][cleanup] TNodify some methods related to prototype and property lookup" · 3a7a4a2f
      Maya Lekova authored 
      This reverts commit 82111e22.

Reason for revert: Speculative revert, could be causing timeouts - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/17567

Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
> 
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
> 
> TNodified:
>  * LoadJSFunctionPrototype
>  * TryPrototypeChainLookup
>  * OrdinaryHasInstance
> 
> Also TNodified loads regarding:
>  * FeedbackCell::kValueOffset
>  * HeapObject::kMapOffset
>  * JSFunction::kSharedFunctionInfoOffset
>  * JSFunction::kFeedbackCellOffset
>  * Map::kInstanceTypeOffset
>  * Map::kInstanceDescriptorsOffset
>  * Map::kPrototypeOffset
> 
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
> 
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}

TBR=rmcilroy@chromium.org,solanes@chromium.org

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

Bug: v8:6949, v8:9396
Change-Id: Ib6ae8fe86a598ed1066894595565e1162cf7dd1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758310Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63233}
      3a7a4a2f
  37. 15 Aug, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [CSA][cleanup] TNodify some methods related to prototype and property lookup · 82111e22
      Santiago Aboy Solanes authored 
      This is a CL in a string of CLs that aims to TNodify CSA. In particular,
there were some loads that were done in AnyTagged instead of
TaggedPointer. TNode-ifying them brings improvement in pointer
compression since we are able to decompress using the Pointer
decompression.

TNodified:
 * LoadJSFunctionPrototype
 * TryPrototypeChainLookup
 * OrdinaryHasInstance

Also TNodified loads regarding:
 * FeedbackCell::kValueOffset
 * HeapObject::kMapOffset
 * JSFunction::kSharedFunctionInfoOffset
 * JSFunction::kFeedbackCellOffset
 * Map::kInstanceTypeOffset
 * Map::kInstanceDescriptorsOffset
 * Map::kPrototypeOffset

Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.

Bug: v8:6949, v8:9396
Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63216}
      82111e22